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FOREWORD 


The  survey  of  simulation  languages  and  programs  was  prepared  for 
ESD  in  order  to  provide  the  Air  Force  a  report  which  would  in  a  form  of  a 
compendium  present  information  on  the  techniques  and  procedures  in 
operation  and/or  in  development  of  ADP  simulation  capabilities.  This 
report  was  prepared  by  The  MITRE  Corporation,  Bedford,  Mass.  ,  under 
contract  No.  F19(628)-71-C-0002,  MITRE  Project  5720.  The  ESD  program 
monitor  is  Mr.  W'illiam  J.  Letendre,  Technology  Application  Division, 
Directorate  of  Systems  Design  and  Development.  Additional  work  on  the 
subject  matter  is  continuing.  Inquiries  regarding  the  current  status  of 
this  effort  should  be  directed  to  the  Deputy  for  Command  and  Management 
Systems,  Directorate  of  Systems  Design  and  Development,  Attn.  Mr. 
W'illiam  J.  Letendre,  L.  G.  Hanscom  Field,  Bedford,  Mass.  01730. 
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ABSTRACT 


This  report  documents  a  survey  of  available  simulation  languages 
and  programs  of  potential  applicability  to  the  simulation  of  ADFE 
systems.  The  major  features  of  the  subject  languages  are  discussed 
and  a  comprehensive  bibliography  is  included. 
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SECTION  I 


INTRODUCTION 


PURPOSE  AND  SCOPE 

This  volume  documents  the  first  phase  of  a  study  of  the 
available  simulation  languages,  programs,  and  techniques  which 
could  be  of  benefit  to  ESD  in  the  simulation  of  ADPE  systems.  Phase 
1  has  consisted  of  an  extensive  survey  of  the  field  of  simulation 
languages  and  has  included  the  preparation  of  a  comprehensive 
bibliography  on  the  subject.  Each  of  the  identified  simulation 
language/packages  is  discussed  with  reference  to  its  historical 
development  and  major  distinguishing  technical  characteristics. 

A  collection  of  documents  considered  to  be  of  a  general, 
tutorial,  or  survey  nature  has  been  assembled;  and  an  annotated 
bibliography  has  been  computerized  for  ease  of  reference  and  rapid 
retrieval  of  pertinent  information. 

In  addition,  a  survey  of  the  literature  for  papers  relative 
to  the  simulation  of  computer  systems  has  been  initiated  and  the 
documentation  is  being  assembled.  This  effort  represents  the 
second  phase  of  the  study  and  will  be  reported  on  in  Volume  2  of 
the  MTR  to  be  released  at  a  later  date. 


ORGANIZATION  OF  THE  REPORT 

The  report  is  organized  into  three  major  sections: 

1.  Theory  of  Simulation 

2.  Simulation  Language/Package  Compendium 

3.  Bibliography 

The  section  on  Theory  of  Simulation  is  included  to  introduce 
the  basic  concepts  and  terminology  of  simulation.  The  treatment  is 
not  definitive;  rather  it  is  only  of  a  depth  necessary  to  assure 
comprehension  of  the  subject  matter  in  the  compendium. 

The  compendium  represents  the  major  content  of  the  report. 
Languages  have  been  classified  as  general  purpose  (suitable  for  the 
simulation  of  discrete,  recursive  systems^)  and  special  purpose 
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Computer  systems  are  so  classified. 
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(designed  specifically  for  the  simulation  of  computer  systems). 
Additionally,  special  purpose  program  packages  exist  for  the 
evaluation  of  computer  systems.  All  of  the  identified  components 
of  each  subject  class  are  discussed.  It  is  the  view  of  the  author 
that  this  report  might  serve  as  a  reference  guide,  and  to  this  end 
some  languages  which  are  only  of  limited  academic  interest  are 
included. 

The  Bibliography  constitutes  the  final  section  of  the  report. 
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SECTION  II 


THEORY  OF  SIMULATION 


MODELING  AND  SIMULATION 

Simulation  is  the  technique  of  constructing  a  model  which  is 
a  representation  of  the  significant  properties  of  an  object,  process, 
or  system  and  then  performing  experiments  on  the  model.  This 
experimentation  serves  to  identify  behavioral  characteristics  and 
makes  possible  the  prediction  of  performance  in  a  real-world 
environment.  Variable  levels  of  abstraction  range  from  the  con¬ 
struction  of  physical  models  to  mathematical  representation. 

The  development  of  large-scale,  digital  computers  coincidental 
with  advances  in  the  theory  of  simulation  has  greatly  expanded  the 
scope  of  studies  which  are  amenable  to  this  methodology.  Simulation 
has  become  a  valuable  tool  for  studying  the  dynamic  responses  of 
systems  that  consist  of  a  large  number  of  interacting  processes  of 
such  a  complex  nature  that  an  analytical  solution  is  practically 
impossible. 

In  a  computer  simulation  the  object  system  is  represented  by  a 
computer  program  which  describes  the  system  components,  the  process 
relationships,  and  the  environment. 


CONTINUOUS  AND  DISCRETE  MODELS 

Simulation  models  are  classified  into  two  major  types:  con¬ 
tinuous  change  models  and  discrete  change  models.  Continuous  change 
models  are  those  in  which  the  system  entities  are  considered  in  the 
aggregate  and  in  a  state  of  continuous  interaction.  These  systems 
are  generally  represented  mathematically  by  a  set  of  n^  order 
differential  equations  that  define  the  rates  at  which  the  system 
variables  change  with  time,  given  specified  constraints  and 
equilibrium  relationships.  Continuous  change  models  have  histori¬ 
cally  been  simulated  on  analog  computers  because  of  their  continuous 
mode  of  operation.  But  in  many  cases  applications  are  restricted 
because  of  hardware  limitations  and  lack  of  accuracy.  Recently, 
digital-analog  simulator  programs  have  been  developed  which  simulate 
the  elements  and  organization  of  analog  computers.  These  allow 
continuous  system  problems  to  be  programmed  for  execution  on 
digital  computers  in  a  manner  approximating  analog  computer  problem 
formulation.  A  discuss. ion  of  this  topic  is  beyond  the  scope  of 
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this  paper;  papers  by  Clancy  and  Fineberg  and  by  Brennan  and 
Linebarger  provide  a  comprehensive  treatment  of  the  subject. 
Languages  developed  for  continuous  change  simulations  are  identified 
and  listed  for  reference  in  Table  I. 

Systems  which  are  characterized  by  changes  which  are  predomi¬ 
nantly  discontinuous  are  called  discrete  systems.  In  this  view  the 
interaction  between  state  variables  occurs  infrequently  and 
,,instantaneously.n  In  reality,  of  course,  all  activity  is  con¬ 
tinuous.  Continuous  activity  is  approximated  by  computing  state 
changes  only  at  the  instants  of  interaction  and  assuming  no  activity 
takes  place  between  interaction  times.  Discrete  systems  are 
modeled  as  network  flow  systems.  A  network  flow  system  is  comprised 
of  components  which  perform  functions  according  to  specified  oper¬ 
ating  rules.  Items  flow  through  the  system  according  to  prescribed 
paths  and  are  processed,  giving  rise  to  sequences  of  events  (i.e., 
changes  in  system  state)  which  frequently  occur  in  a  stochastic 
manner. 

DISCRETE  SIMULATION  LANGUAGES 
Historical  Background 

Discrete  systems  simulation  traces  its  early  origin  to  the 
field  of  operations  research  and  in  particular  to  the  statistical 
technique  of  distribution  sampling.  In  the  early  1950's  Monte 
Carlo  techniques  were  applied  without  benefit  of  a  computer  to  the 
study  of  the  dynamic  behavior  of  physical  systems.  With  advances 
in  the  field  of  computer  technology,  these  studies  became  prime 
candidates  for  automation.  The  first  programs  were  special-purpose 
models,  coded  in  assembly  or  compiler  language,  each  designed  to 
solve  a  specific  problem.  As  experience  was  gained  techniques 
applicable  to  specific  classes  of  problems  (i.e.,  job-shop  and 
inventory  management  simulations)  were  abstracted  and  implemented 
to  produce  special  purpose  computer  simulation  packages.  To  use 
these  the  analyst  supplies  parameter  values  and  control  variables 
which  are  specific  to  his  application. 

General-purpose  simulation  programming  languages  applicable  to 
a  wide  range  of  discrete-change  models  originated  in  the  late  1950's 
and  have  evolved  since  then  through  the  incorporation  of  advanced 
concepts,  as  theories  of  simulation  have  been  formalized. 

Common  Features 


Simulation  languages  are  specialized  algorithmic  languages 
which  provide  features  of  particular  relevance  to  simulation.  While 
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Table  I 


Continuous 


ASTRAL 

BHSL 

BLODI 

360/CSMP 

COBLOC 

CSSL 


DAS 

DEPI 

DEPI-4 

DES-1 

DIAN 

DIDAS 

DSL/ 90 

DYANA 

DYNAMO 

DYNASAR 

DYSAC 

EASL 

FORBLOC 

HYBLOC 

JANIS 


Change  Simulation  Languages/Packages 


MADBLOC 
MI  DAL 

MIDAS  and  ENLARGED  MIDAS 
MIMIC 

PACER 

PACTOLUS 

PARTNER 

PLIANT 


SADSAC 

SALEM 

SCADS 

SIMTRAN 

SLANG 

SLASH 

SPLASH 

TAF 

UNI TRAC 
WIZ 
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they  differ  in  their  conceptualization  of  a  "world  view"2  and  in 
their  manner  of  implementation,  all  provide  the  necessary  facilities 
to  describe  the  object  system's  static  and  dynamic  structure.  The 
basic  components  of  a  simulation  language  include: 

1*  A  data  structure  which  allows  for  the  identification, 
description,  classification  and  manipulation  of  the  constituent 
entities  of  a  system. 

2.  A  collection  of  commands  to  modify  the  state  of  the  system. 

3.  A  master  timing  routine  to  provide  the  sequencing  control. 

4.  A  capability  to  generate  pseudo-random  numbers  from  speci¬ 

fied  probability  distributions. 

5.  Facilities  for  the  aggregation  and  presentation  of  the 
statistical  results. 


WORLD  VIEW 

A  description  of  a  real  world  system  consists  of  two  prime 
components: 

1.  A  static  representation. 

2.  A  dynamic  representation. 

Kiviat  states:  "The  static  structure  of  a  simulation  model  is 
a  time-independent  framework  within  which  system  states  are  defined... 
Dynamic  system  processes  act  and  interact  within  a  static  data 
structure,  changing  data  values  and  thereby  changing  system  states."^ 

Static  Representation 

The  static  structure  of  a  system  is  described  in  terms  of  the 
objects  which  it  contains  and  the  relationships  that  exist  between 
objects.  Objects  are  characterized  by  attributes  or  properties 


2 

Krasnow  and  Merikallio  define  "world  view"  to  be  "the  conceptual 
foundation  upon  which  a  representation  of  a  system  may  be  built." 
Howard  S.  Krasnow  and  Reino  A.  Merikallio,  "The  Past,  Present,  and 
Future  of  General  Simulation  Languages,"  Management  Science,  Vol.  11, 
No.  2,  November  1964,  p.  237. 

3 

"Philip  J.  Kiviat,  "Digital  Computer  Simulation:  Computer  Program¬ 
ming  Languages,"  RAND  Memorandum  RM-5883-PR,  January  1969,  p.  10. 
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whose  values  may  be  permanent  or  temporary.  The  status  of  an  object, 
at  any  point  in  time,  is  uniquely  defined  by  the  values  of  its 
attributes. 

Because  of  the  large  number  of  objects  in  a  typical  system  and 
because  of  a  lack  of  uniqueness,  objects  are  aggregated  into  classes. 

A  system  is  defined  in  terms  of  its  constituent  classes  and  a  quali¬ 
tative  delineation  of  the  set  of  attributes  associated  with  each. 

The  actual  status  of  each  object  is  defined  dynamically  as  the  simu¬ 
lation  model  is  exercised. 

The  data  structures  onto  which  these  status  descriptions  are 
mapped  and  the  referencing  techniques  are  functions  of  the  language 
design.  Many  languages  allow  for  the  dynamic  creation  and  destruction 
of  objects  and  provide  the  capabilities  to  form  disjoint  classes  of 
objects  based  on  differences  in  status.  Ordered  sets  are  used  for 
representing  queues  and  files  of  objects.  The  languages  provide 
operators  of  varying  power  to  manipulate  set  memberships • 

Dynamic  Structure 

The  dynamic  structure  of  a  system  is  concerned  with  representing 
the  possible  state  changes  within  a  system  and  the  sequential  relation¬ 
ships  that  exist  between  them.  Every  simulation  program  is  comprised 
of  modules  which  describe  specific  system  behavior  patterns  and  an 
executive  routine  which  provides  the  time  mechanism  and  the  control 
to  assure  the  execution  of  the  modules  in  the  proper  time,  logic  and 
priority  sequence. 

Simulation  languages  may  be  classified  according  to  their  prin¬ 
cipal  dynamic  modeling  orientation: 

1.  Event-oriented  languages. 

2.  Activity-oriented  languages. 

3.  Process-oriented  languages. 

An  event  represents  a  change  in  state.  It  is  conceptualized  as 
occurring  instantaneously  and  taking  no  time.  In  contrast,  an 
activity  represents  a  time  consuming  action  within  the  system  and  is 
bounded  by  two  events,  namely  the  initiation  and  the  termination  of 
the  action.  A  process  is  a  set  of  events  which  are  associated  with 
a  specific  system  behavior  pattern.  It  is  like  an  activity  in  that 
it  exists  over  a  period  of  simulated  time.  The  characteristics  of 
some  physical  systems  are  such  that  they  would  dictate  the  choice  of 
one  language  class  as  dominant  for  the  execution  of  a  simulation 
study. 
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The  terminology  event-oriented  simulation  derives  from  the  fact 
that  the  model  is  segmented  into  routines  called  events.  These 
routines  consist  of  procedural  statements  describing  the  instan¬ 
taneous  changes  in  system  state  which  result  from  the  occurrence  of 
the  subject  events.  An  event  is  scheduled  (i.e.,  assigned  a  time  of 
occurrence)  by  special  language  statements  either  when  the  logic  of 
the  model  indicates  that  all  necessary  conditions  have  been  satisfied, 
or  alternatively,  when  a  random  drawing  from  a  specified  statistical 
distribution  indicates  that  it  should  be  scheduled.  Schedule 
occurrence  times  are  maintained  on  an  event  list.  It  is  the  function 
of  the  executive  program  to  maintain  both  the  currency  and  the 
chronology  of  the  list  and  to  execute  the  proper  subprogram  as  each 
event  "occurs"  in  simulated  time. 

An  activity-oriented  simulation  language  differs  from  an  event- 
oriented  one  in  that  it  contains  no  explicit  scheduling  statements 
within  its  repertoire.  Under  this  conceptual  approach,  the  model 
is  segmented  into  modules  called  activities.  A  module  consists  of 
both  (1)  a  description  of  the  time  consuming  action  which  produces 
change  in  system  status,  and  (2)  the  set  of  conditions  upon  which 
the  initiation  of  the  action  depends.  Within  activity  modules 
element  clocks  are  maintained  which  indicate  the  time  at  which 
entities  associated  with  the  activity  are  due  to  change  state.  The 
action  section  is  comprised  of  a  set  of  state-changing  and  time¬ 
setting  instructions. 

In  an  activity-oriented  model  the  scheduling  is  achieved  via 
the  mechanism  of  an  activity  scan.  Before  each  simulated  time 
advance,  the  control  program  scans  all  activities,  testing  the  con¬ 
ditions  and  determining  the  potential  of  each  for  execution.  If 
all  test  conditions  are  satisfied,  the  action  section  is  executed, 
otherwise  control  is  transferred  to  the  next  activity.  This  pro¬ 
cedure  is  repeated  in  cyclic  fashion  to  account  for  the  inter¬ 
dependency  between  the  activities.  To  improve  operational  efficiency, 
some  activity-oriented  languages  also  incorporate  the  feature  of  an 
event  list  to  schedule  events  which  are  non-interactive. 

The  third  orientation  for  the  modeling  of  system  dynamics  is 
the  process  concept.  A  process,  as  previously  defined,  is  a  set  of 
events  which  are  descriptive  of  a  specific  system  behavior  pattern. 

It  represents  a  combination  of  both  the  activity  and  event  formula¬ 
tions.  In  a  process-oriented  simulation  the  model  is  segmented  into 
units  called  processes  each  of  which  consists  of  multiple  event 
subprograms.  The  execution  of  a  process  extends  over  system  time 
and  consists  of  alternate  periods  of  activity  and  inactivity.  Only 
one  process  is  in  the  active  state  at  any  point  in  time  but  processes 
interact  and  are  joined  together  by  time-dependent  or  status-dependent 
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conditions.  Thus  the  outcome  of  a  simulation  study  is  described  by 
the  sequence  of  active  phases  of  the  component  processes.  This  mode 
of  operation  has  been  defined  as  quasi-parallel. 

In  addition  to  arithmetic  and  logic  statements,  sequencing 
statements  are  provided  which  cause  the  transfer  of  control  from 
process  to  process.  The  execution  of  a  sequencing  statement  causes 
control  to  leave  the  process,  and  the  location  following  such  a 
statement  is  defined  as  a  reactivation  point.  Control  is  transferred 
back  to  this  point  at  the  initiation  of  the  next  active  phase  of  the 
process.  Proper  sequencing  is  maintained  by  an  executive  program. 
Event-scheduling  techniques  are  employed  when  a  time-oriented 
scheduling  statement  is  encountered,  and  an  activity-scan  is 
initiated  when  a  condition-oriented  scheduling  statement  is  encoun¬ 
tered. 

This  method  has  some  obvious  advantages.  It  allows  for  the 
concise  notation  of  activity-oriented  languages  which  is  useful  in 
describing  highly  interactive  processes  and  takes  advantage  of  the 
increased  run  time  efficiency  of  event  scheduling.  The  result  is 
a  highly  sophisticated  executive  program. 

Some  authors  further  classify  simulation  languages  as  machine 
or  material  based.  If  the  major  emphasis  of  the  system  study  is 
the  observation  of  actions  executed  by  entities,  the  system  is  con¬ 
sidered  machine  oriented;  conversely,  if  the  emphasis  is  on  the 
observation  of  actions  performed  upon  entities,  the  system  is 
material  oriented. 


SIMULATION  LANGUAGE  TECHNIQUES 
Timing  Concepts 

In  a  computer  simulation  the  independent  variable  is  time.  A 
master  timing  routine  must  provide  the  point  of  reference  within 
the  model  to  control  the  advancement  of  time.  It  must  also  provide 
the  scheduling  logic  to  control  this  advancement  in  a  manner  con¬ 
sistent  with  the  time  and  sequence  relationships  between  the  com¬ 
ponents  of  the  simulated  system.  The  problem  is  complicated  by  the 
fact  that  computers  are  sequential  in  nature  while  real  world 
physical  systems  are  sometimes  characterized  by  the  occurrence  of 
many  parallel  and  interdependent  activities. 

Basic  to  the  representation  of  simulation  time  is  the  concept 
of  a  master  simulation  clock.  It  is  a  variable  which  i3  successively 
updated  to  represent  the  current  point  on  the  simulation  time  scale. 
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The  first  simulation  clocks  were  counters  that  were  advanced  in 
fixed  increments  representing  the  basic  time  unit  of  the  simulation 
(i.e.,  seconds,  minutes,  hours,  etc.).  The  system  was  examined  every 
unit  of  clock  time,  to  determine  whether  any  events  were  due  to  occur. 
Fixed  time  increment  methods  are  computationally  efficient  in  the 
simulation  of  systems  in  which  events  occur  with  predictable 
regularity.  When  this  is  not  the  case,  the  method  leads  to  long 
periods  during  which  the  computer  is  11  idle. 11 

An  alternative  concept  for  controlling  time  has  been  called 
next-event  or  critical  event  simulation.  This  method  involves 
scanning  the  event  list  and  advancing  the  master  simulation  clock 
by  the  amount  necessary  to  cause  the  occurrence  of  the  next  most 
imminent  event.  In  this  manner  the  program  is  stepped  from  event 
to  event,  maximizing  operational  efficiency  by  compressing  those 
increments  of  time  in  which  no  state  changes  occur.  Since  most 
physical  systems  are  categorized  by  the  occurrence  of  non-periodic 
random  changes,  the  variable  time  increment  method  of  controlling 
time  has  been  implemented  in  the  vast  majority  of  discrete  simu¬ 
lation  languages. 

List  Processing 

The  state  of  a  system  at  any  point  in  time  is  completely 
specified  by  the  list  of  entities,  their  associated  attributes  and 
set  memberships.  The  process  of  simulation  consists  of  changing 
the  relationships  among  these  data  as  a  function  of  time.  Hence, 
data  structures  and  list  processing  techniques  are  of  importance 
for  accessing  and  updating  this  information. 

List  processing  techniques  are  utilized  in  the  representation 
and  management  of  queues  and  in  the  scheduling  of  events.  Lists 
are  series  of  words  in  non-contiguous  storage  whose  relationships 
are  maintained  by  the  use  of  pointers.  Chaining  techniques 
associate  entities  with  their  attributes  and  set  memberships.  This 
capability  facilitates  the  ability  to  change  set  memberships,  to 
scan  for  entities  possessing  specific  attributes,  and  to  maintain 
queue  discipline. 

Computer  storage  is  usually  dynamically  allocated.  This  is 
appropriate  since  the  dynamic  nature  of  simulation  is  such  that  the 
lengths  of  queues  and  set  memberships  are  variable  and  change  as  a 
function  of  time. 
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Random  Number  Generation 


Simulation  studies  are  characterized  by  the  random  and  probaba- 
listic  occurrence  of  events.  Basic  to  simulation  languages  is  the 
incorporation  of  techniques  to  allow  for  the  generation  of  random 
variables,  the  transformation  of  these  into  variates  from  specified 
statistical  distributions,  and  the  maintenance  of  independent  and 
reproducible  streams  of  random  numbers.  The  following  are  representa¬ 
tive  of  the  distributions  commonly  available  in  discrete  simulation 
languages: 


1.  Normal 

2.  Poisson 

3.  Geometric 

4.  Exponential 

5.  Rectangular 
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SECTION  III 


SIMULATION  LANGUAGE/PACKAGE  COMPENDIUM 


This  section  presents  the  results  of  a  survey  of  simulation 
languages/packages  which  might  have  applicability  in  the  simulation 
of  ADPE  systems.  While  some  languages  are  not  applicable  or  are 
obsolete,  they  have  been  included  for  historical  reasons. 

The  languages/packages  have  been  classified  by  major  orienta¬ 
tion  as: 

1.  General  Purpose  Simulation  Languages 

2.  Computer  Systems  Simulation  Languages 

3.  Computer  Systems  Simulation  Packages 

Each  language  is  described  within  a  common  format: 

Background  Information 
Author 

Originating  Organization 

Date  of  Release 

Status 

Machine  Implementations 

Major  Features 

Applications 

References 

The  information  is  as  described  in  the  literature.  No  attempt 
has  been  made  at  verification;  and  especially  in  the  matter  of  ma¬ 
chine  implementation,  the  data  may  be  incomplete. 

As  stated  previously,  Volume  2  of  this  report  will  cover  in 
depth  the  use  of  simulation  languages  in  the  modeling  of  computer 
systems.  Therefore,  information  relevant  to  applications  is  not 
consistently  included  and  is  of  a  general  and  cursory  nature. 
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GENERAL  PURPOSE  SIMULATION  LANGUAGES 
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AS  -  An  ALGOL  Simulation  Language 


1.  Background  Information 
Author:  R.  D.  Parslow 

Originating  Organization:  Brunei  University,  London 

Date  of  Release:  1967 

Status:  Under  continuous  revision 

Machine  Implementation:  Written  for  KDF9  at  National  Physics 

Laboratory,  adaptable  to  any  machine 
with  ALGOL  compiler* 


2.  Major  Features 

AS,  an  activity  oriented  language,  consists  of  a  collection  of 
ALGOL  procedures  designed  to  provide  the  basic  capabilities  necessary 
for  simulation.  It  enables  the  user  to  write  a  simulation  program 
in  ALGOL  incorporating  the  relevant  modules  from  the  package.  Its 
method  of  operation  is  derived  from  GSP  (General  Simulation  Program) 
by  K.  D.  Tocher. 

Matrix  notation  is  used  to  record  the  system  elements,  both 
static  and  dynamic,  together  with  their  associated  data. 

The  system  elements  are  defined  as  follows: 

a.  ents  —  time  dependent  entitles 

b.  depots  —  serve  as  records  or  represent  stores 

c.  activities 

b  act  —  bound  activity,  set  to  operate  on  a  partic¬ 
ular  entity  at  a  predetermined  time 

c  act  —  conditional  activity,  requires  availability 
of  several  entities 

d.  pools  —  sets  of  entities  possessing  a  common  attribute; 

pools  may  themselves  consist  of  sets  of  pools 
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The  matrix  notation  facilitates  the  dynamic  operation  of  the 
system  and  provides  easy  access  to  such  information  as: 

a.  Entities 

*  status  -  busy  or  idle 

*  time  of  completion  if  busy 

*  next  scheduled  b  act 

*  committal  parameters  (i.e.,  distribution  type  and  para¬ 
meters,  randon  stream,  etc.) 

*  final  location  in  pool  at  completion 

b.  Pools 

*  number  of  members 

*  earliest  time  of  availability 

*  reference  number  of  earliest  available  member 

c.  Activities 

b  act 

*  committal  parameters  for  entities  engaged  in 
multiple  activities 

c  act 

*  records  ents  or  pools  required  for  c  acts 

d.  Utilization  of  entities  and  pools 

*  total  number  of  activities  engaged  in 

*  total  committal  time 

The  phase  structure  is  controlled  by  the  procedure  "next"  which 
is  called  at  the  completion  of  each  activity  block  in  the  object  pro¬ 
gram.  It  controls  the  cycles  of  four  phases  of  the  simulation: 
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a.  T-Phase  -  advances  time  to  the  next  event-  This  is  facil¬ 

itated  by  grouping  time-dependent  entities  into 
pools.  The  minimum  time  for  each  pool  is  recorded 
in  the  matrix. 

b.  B-Phase  -  scans  all  entities  to  enter  all  bound  activities 

due  and  to  release  working  entities  whose  committal 
time  is  over.  A  tolerance  value  may  be  input  which 
allows  the  grouping  of  all  events  due  to  occur 
within  the  specified  AT. 

c.  C-Phase  -  causes  transfer  to  the  first  conditional  activity. 

Conditions  are  tested  by  a  Boolean  procedure 
"c  act."  If  satisfied:  activity  is  committed. 

If  not  satisfied:  enter  A-Phase  which  tests  if 
unavailable  entities  will  be  free  after  present 
task  and  if  so  reserves  them  for  the  specific 
"c  act." 

After  the  execution  of  the  C-Phase,  control  is  transferred  back  to 
the  T-Phase. 

The  major  emphasis  in  the  development  of  the  language  was  to 
provide  a  framework  within  which  simulation  studies  could  be  easily 
formulated  and  speed  of  operation  was  considered  to  be  of  secondary 
importance. 


Reference 

R.  D.  Pars low,  "AS:  An  ALGOL  Simulation  Language,"  in  J.  N.  Buxton, 
ed. ,  Simulation  Programming  Languages,  North  Holland,  Amsterdam, 
1968,  pp.  86-100. 
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CLP  -  The  Cornell  List  Processor 


1.  Background  Information 

Authors:  J.  W.  Conway 

J.  J.  Delfausse 
W.  L.  Maxwell 
W.  E.  Walker 

Originating  Organization:  Cornell  University,  Department  of 

Engineering 

Date  of  Release:  1964 
Status:  Current 

Machine  Implementation:  Control  Data  1604 

Burroughs  220 

2.  Major  Features 

CLP  was  developed  as  a  teaching  vehicle  to  introduce  the  concepts 
of  simulation  and  other  list  processing  techniques  in  a  language  that 
did  not  require  a  high  level  of  programmer  expertise.  This  was  accom¬ 
plished  by  including  CORC,  a  general  algebraic  language,  as  a  subset 
of  CLP. 

The  major  feature  of  the  language  is  a  special  purpose  data 
element  called  an  entity  which  has  associated  properties  called 
attributes.  Entities  are  dynamic  in  that  the  number  varies  as  a 
function  of  time.  Special  language  statements  allow  for  the  creation 
and  destruction  of  entities  and  for  the  creation  of  sets  ordered  on 
the  value  of  a  particular  attribute  of  its  component  members.  The 
dynamic  assignment  of  core  storage  and  overlay  techniques  make  pos¬ 
sible  the  ephemeral  nature  of  the  data  structure. 

CLP  derives  some  of  its  concepts  from  SIMSCRIPT,  in  particular 
it  incorporates  a  Report  Generator  to  specify  variable  output  formats. 
It  does  not  include  a  timing  routine  and  this  function  remains  a 
programmer  responsibility. 

Reference 

R.  W.  Conway,  J.  J.  Delfausse,  W.  L.  Maxwell,  W.  E.  Walker,  "CLP  -  The 
Cornell  List  Processor,”  Communications  of  the  ACM,  Vol.  8,  No.  4, 
April  1965,  pp.  215-216. 
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CSL  -  Control  and  Simulation  Language 


1.  Background  Information 

Authors:  J,  N,  Buxton 
J.  G.  Laski 

Originating  Organization:  CSL  -  ESSO  Petroleum  Co.,  Ltd.  and 

IBM  United  Kingdom,  Ltd. 

CSL2  -  IBM  United  Kingdom,  Ltd. 

ECSL  -  Courtaulds,  Ltd.  and 

Honeywell  Controls,  Ltd. 

Date  of  Release:  1963 

Status:  CSL  Current 

CSL2  in  Preparation 
ECSL  Current 

Machine  Implementation:  CSL  -  IBM  7090 

CSL2  -  IBM  7090/7094 

ECSL  -  Honeywell  400  and  200  Series 


2.  Major  Features 

CSL  is  a  programming  language  designed  to  simulate  industrial 
scheduling  and  waiting  line  systems  involving  logical  decisions  of 
great  complexity.  It  is  a  descendant  of  GSP;  and  although  developed 
independently,  it  has  many  conceptual  features  similar  to  SIMSCRIPT. 

The  language  was  designed  as  an  experiment  to  test  the  premise 
that  a  combination  of  the  techniques  of  queueing  theory  with  those 
of  predicate  calculus  would  provide  a  capability  for  the  formulation 
and  solution  of  complex  logical  problems.  As  a  result  the  principal 
feature  of  CSL  is  the  concept  of  sets  whose  members  are  entities 
which  are  in  a  specific  state  or  possess  a  common  attribute.  Since 
the  order  in  which  entity  names  are  placed  on  a  set  is  preserved  at 
all  times,  a  set  can  be  used  to  represent  a  queue  of  its  members. 

The  language  offers  extensive  facilities  for  set  creation  and  manip¬ 
ulation.  The  state  of  a  system  at  any  point  in  time  is  defined  by 
lists  of  entities  belonging  to  each  set  in  the  system  and  by  their 
attribute  values  stored  in  arrays. 
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A  CSL  program  is  divided  into  sectors  called  "activities"  which 
completely  describe  all  possible  operations  within  the  system.  Each 
activity  includes  a  set  of  conditions  which  must  be  satisfied  before 
a  specific  operation  of  the  system  can  be  initiated  and  a  specification 
of  state  changes  which  are  enacted  if  the  conditions  are  satisfied. 

This  type  of  sequencing  is  defined  as  interrogative  sequencing  and 
is  necessitated  by  the  inability  to  predict  in  advance  the  system 
time  at  which  a  given  event  should  take  place. 

Time  in  a  CSL  simulation  is  controlled  via  the  mechanism  of  T- 
cells  which  are  associated  with  entities  and  indicate  the  time  at 
which  the  entity  is  next  due  to  change  its  state.  All  time  values 
are  relative  to  the  present  simulated  instant.  Time  advancement  is 
controlled  via  a  repeated  two-phase  process.  During  Phase  1  all  time 
cells  are  scanned  to  locate  the  smallest,  positive,  non-zero  value. 
Simulated  time  is  advanced  by  this  amount,  and  all  T-cells  are  corre¬ 
spondingly  reduced.  Phase  2  consists  of  an  attempt  to  execute  each 
activity  in  sequence.  During  the  activity  scan  the  conditions  for 
each  activity  are  tested,  and  unless  explicitly  stated  otherwise  the 
standard  path  is:  after  success  go  to  next  statement,  after  failure 
go  to  next  activity.  Each  instance  of  an  activity  constitutes  an 
event.  To  allow  for  interdependency  between  events,  the  RECYCLE 
statement  causes  the  activity  list  to  be  rescanned  at  the  same 
simulated  time. 

The  form  of  arithmetic  and  assignment  statements  is  similar  to 
FORTRAN.  In  the  initial  version  of  the  language,  CSL  statements  were 
first  compiled  into  FORTRAN  statements  before  compilation  into  IBM 
7090  machine  code.  Newer  versions  of  the  language,  CSL2  and  ECSL 
(Extended  Control  and  Simulation  Language) ,  have  abandoned  this 
approach;  and  compilers  are  available  to  translate  directly  into 
assembly  language  for  IBM  and  Honeywell  computers  respectively. 

This  is  a  more  efficient  mode  of  operation  and  allows  for  extensions 
to  the  language  not  previously  possible  because  of  FORTRAN  restrictions. 

3.  Application 

In  an  extract  from  a  forthcoming  work  by  Buxton  and  Laski,  the 
authors  express  the  opinion  that  the  language  is  not  well  suited  to 
describing  problems  which  are  concerned  with  flow  and  in  which  the 
logical  decisions  made  are  not  of  great  complexity.  Examples  cited 
are  the  flow  of  information  through  a  computing  system  or  the  flow 
of  work  through  a  single  production  unit. 
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ESP  -  The  ISlliott  Stimulator  Package 


1.  Background  Information 

Author:  J.  W.  J.  Williams 

Originating  Organization:  Elliot  Scientific  Computing  Division 

Date  of  Release:  1964 

Status:  Current 

Machine  Implementation:  Elliot  503  and  803 

2.  Major  Features 

ESP,  an  activity  oriented  language  based  on  GSP,  is  comprised 
of  a  set  of  ALGOL  procedures. 

The  system  concept  is  that  of  a  set  of  actions  which  manipulate 
a  set  of  objects.  Objects  are  represented  numerically,  and  the 
actions  are  represented  by  program  segments.  Actions  have  been 
categorized  into: 

a.  delayed  —  scheduled  to  occur  at  a  specific  time 

b.  conditional  —  dependent  upon  the  satisfaction  of  a  set 

of  logical  conditions 

Each  delayed  action  is  represented  by  a  program  segment,  while  all 
conditional  actions  are  grouped  into  a  single  section. 

The  process  by  which  the  occurrence  of  a  delayed  action  is 
scheduled  is  referred  to  as  "calling"  that  action.  Any  action  may 
call  any  other  including  itself.  The  statement  "call  (i,t)" 
schedules  the  i**1  delayed  action  to  be  executed  after  t  time  units 
have  elapsed.  Parameters  are  transferred  via  the  "send  and  get" 
arrays  and  are  made  available  at  the  time  of  scheduling.  This 
produces  sets  of  local  variables  defined  in  time.  The  use  of 
sophisticated  sorting  routines  and  dynamic  storage  allocation 
provides  for  multiple  occurrence  of  each  event  with  independent 
sets  of  parameters. 
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The  ESP  program  controls  the  maintenance  of  simulation  time  and 
the  correct  sequencing  of  actions.  This  is  accomplished  in  the 
following  manner.  A  list  of  times  of  pre-scheduled  (i.e.,  delayed) 
actions  is  scanned  by  a  procedure  called  '’next/'  and  the  action(s) 
associated  with  the  minimum  time  is  executed.  After  this  the  condi¬ 
tional  actions  are  tested  sequentially,  and  any  whose  criteria  for 
operation  are  satisfied  are  also  executed.  The  two  stage  cycle  is 
then  repeated. 

Additional  features  include  facilities  for  generation  of  inde¬ 
pendent  streams  of  random  numbers,  construction  of  histograms,  and 
manipulation  of  queues. 


Reference 

J.  W.  J.  Williams,  "ESP  -  The  Elliott  Simulator  Package,"  Computer 
Journal,  January  1964,  pp.  328-331. 
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FORSIM  IV 


1.  Background  Information 
Author:  E.  Famolari 

Originating  Organization:  The  MITRE  Corporation 
Date  of  Release:  1964 
Status:  Current 

Machine  Implementations:  IBM  7030  GE  635 

IBM  7090  CDC  3400 

IBM  7094  CDC  3600 

IBM  360/50 


2.  Major  Features 

FORSIM  IV  is  a  subroutine-structured  general  purpose  simulation 
language  written  (with  very  minor  exceptions^)  in  FORTRAN  IV.  With 
minimal  effort  it  can  be  adapted  to  any  computer  with  a  FORTRAN  IV 
compiler  and  may  therefore  be  considered  "machine-independent . ,f 

The  conceptual  framework  of  the  language  is  based  on  that  of 
the  Control  and  Simulation  Language  (CSL).  However,  it  provides 
additional  capabilities,  and  the  modular  structure  allows  for  easy 
expansion  of  the  command  set. 

FORSIM  IV  employs  the  concepts  of  entity,  class,  and  set  with 
the  standard  definitions.  Sets  serve  the  same  function  as  in  GPSS; 
that  is,  as  stores,  facilities,  and  queues.  The  set  of  subroutines 
which  perform  the  actions  and  tests  associated  with  the  relationships 
between  sets,  entities,  and  attributes  is  classified  as  Set-Entity. 

It  provides  the  unifying  concept  for  the  50  subroutine  components 
of  the  package,  allowing  the  entities  to  be  accessed  by  the  use  of 
index  values.  A  complete  classification  of  the  command  routines  is: 

a.  Set-Entity 

b.  Time 


^The  debug  routine  and  random  number  generators  were  written  in 
STRAP,  the  7030  machine  code. 
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c.  Histogram 

d.  Statistical 

e.  Random  number  and  debug 

Set-Entity  routines  are  further  classified  as  Action  routines,  which 
perform  unconditionally,  and  Dual  routines,  which  perform  only  if 
certain  logical  conditions  are  met. 

The  I/O,  arithmetic,  decision  logic,  and  normal  processing 
functions  are  provided  by  FORTRAN  IV.  The  program  consists  of  the 
appropriate  FORTRAN  IV  statements  and  FORSIM  IV  subroutines  organized 
in  a  manner  which  reflects  the  logic  of  the  simulated  system.  In 
general  terms  the  program  will  consist  of  initialization,  working, 
and  termination  sections.  The  working  section  is  comprised  of  a 
sequence  of  routines  each  describing  a  unique  type  of  system  action 
involving  time-dependent  or  dynamic  elements  of  the  system.  Each 
routine  is  termed  an  Activity,  and  the  sequences  is  called  a  List. 

Time  is  advanced  in  variable  time  increments  to  the  next  most 
imminent  action  time.  The  dynamics  of  the  language  allow  time  to 
be  associated  with  both  entities  and  activities.  A  recycle  feature 
allows  an  additional  cycle  through  the  activities  list  with  the 
simulation  time  held  constant. 


Reference 

E.  Famolari,  "FORSIM  IV  User's  Guide  SR-99,"  The  MITRE  Corporation, 
February  1964. 
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GASP  -  £eneral  Activity  Simulation  Program 
1.  Background  Information 

Author:  Original  Version:  P.  J.  Kiviat 

Revised  Version:  J.  Belkin  &  M.  R.  Rao 

Originating  Organization:  United  States  Steel  Corporation 

Applied  Research  Laboratory 

Date  of  Release:  Original  Version:  1963 

Revised  Version:  1965 

Status:  Current 

Machine  Implementation:  IBM  1130,  1620,  1830,  7040/7044,  7090/7094 

GE  225,  415 

XDS  930 

NCR  315 

XDS  Sigma  7 

Burroughs  3500,  5500 

CDC  3400,  G-20 


2.  Major  Features 

GASP  consists  of  a  collection  of  23  FORTRAN  subroutines  designed 
to  be  used  in  FORTRAN-written  simulation  programs.  These  routines 
are  representative  of  operations  common  to  computer  simulations.  A 
simulation  utilizing  GASP  consists  of  a  set  of  FORTRAN  subroutines, 
called  GASP  events,  that  are  organized  via  the  GASP  EXECUTIVE,  which 
maintains  the  temporal  order  of  the  model.  This  approach  has  the 
dual  advantages  of  modularity  and  machine  independence. 

GASP  provides  the  facilities  to: 

a.  control  the  sequence  of  activities 

b.  maintain  list  structures 

c.  sample  from  statistical  distributions 

d.  aggregate  results  and  compute  statistics 

e.  automatically  monitor  program  variables  and  fLc* 
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Special  symbols  and  GASP-oriented  conventions  are  used  to 
describe  system  behavior  in  the  form  of  flow  charts  which  delineate 
operations,  decisions,  transfers  and  control.  These  flow  charts  are 
then  translated  into  FORTRAN  statements. 

The  basic  component  in  GASP  is  termed  an  element.  It  may  be 
permanent  or  temporary  and  is  described  by  a  set  of  attributes.  The 
logic  that  describes  the  interaction  of  elements  and  the  attendant 
change  of  system  status  is  called  an  event.  It  occurs  instantaneously 
in  time  and  represents  the  beginning  and/or  end  of  an  activity.  Each 
event  is  written  as  a  separate  FORTRAN  subroutine  which  is  executed 
when  the  event  "occurs"  in  simulated  time. 

It  is  the  function  of  the  GASP  executive  program  to  maintain  the 
proper  chronology  between  the  events.  This  is  achieved  via  an  Mevent 
list"  ordered  on  the  time  of  occurrence  of  each  scheduled  event. 

GASP  is  a  variable-increment  time  model  in  which  the  scheduling  of 
events  is  the  only  mechanism  of  advancing  time.  This  is  accomplished 
within  GASP  events;  each  event  is  capable  of  scheduling  itself  or  any 
other  event. 


Reference 

P.  J.  Kiviat,  nGASP  -  A  General  Activity  Simulation  Project," 
available  from  Applied  Research  Laboratory,  United  States  Steel, 
Monroeville,  Pa.,  1963. 
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GPSS  -  General  Purpose  Slystem  Simulator 


1.  Background  Information 

Authors:  R.  Efron 
G.  Gordon 


Originating  Organization: 


GPSS  (B5500) 

GPSS  III 

GESIM 

GPS-K 

GPSS/360 

Flow  Simulator 

GPSS  II 

GPDS 


-  Burroughs,  GPSS/360  capability 

-  Control  Data  Corp. 

-  General  Electric,  GPSS/360  capability 

-  Honeywell 

-  IBM 

-  RCA,  GPSS/360  capability 

-  Univac,  FORTRAN  implementation 

-  Xerox  Data  Systems,  GPSS/360  capability 

due  February  1971 


Date  of  Release:  Several  versions,  the  first  of  which  appeared 

in  the  early  1960's 


Status:  Maintained  and  supported  by  IBM 


Machine  Implementation: 


GPSS 

GPSS  III 

GESIM 

GPS-K 

GPSS/360 

Flow  Simulator 

GPSS  II 

GPDS 

2.  Major  Features 


-  B5500 

-  CDC  3600 

-  GE  600  series 

-  Honeywell  200  series 

-  IBM  360 

-  RCA  Spectra  70 

-  Univac  1107-1108 

-  XDS  Sigma  5,  7 


GPSS  has  been  extended  and  improved  since  its  origination,  and 
present  implementations  (e.g.,  GPSS/360)  provide  a  versatile  and 
fairly  powerful  language  which  can  be  learned  and  applied  by  non¬ 
programmers  in  a  rather  minimal  amount  of  time.  These  desirable 
characteristics  derive  primarily  from  the  block  diagram  nature  of 
the  language.  The  system  being  simulated  is  modeled  ^ing  a  fixed 
set  of  predefined  block  types.  These  block  types  represent  the 
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various  actions  and  functions  occurring  in  real  systems.  The  inter¬ 
connections  between  these  block  types  in  a  particular  system  model 
reveal  the  structure  of  the  system;  i.e. ,  the  ordering  of  the  succession 
of  events.  Since  there  exists  a  one-to-one  correspondence  between 
blocks  and  GPSS  coding,  a  model  can  be  encoded  directly  from  its 
diagram.  GPSS  is,  therefore,  a  highly  structured  language  relying 
on  predefinition  for  power  and  simplicity. 

GPSS  has  other  advantages,  particularly  to  the  novice.  Statis¬ 
tical  analyses  of  system  events  are  provided  automatically,  along 
with  a  rather  extensive  set  of  error  diagnostics.  For  all  the  above 
reasons,  GPSS  has  achieved  the  wide  acceptance  indicated  by  the  machine 
implementation  schedule  shown  above.  It  is  certainly  beneficial  to 
the  GPSS  user  that  he  can  find  GPSS/360  capability  with  machines  made 
by  Burroughs,  GE,  RCA,  and  XDS,  as  well  as  IBM. 

On  the  negative  side,  GPSS  does  suffer  some  drawbacks  relative 
to  other  alternatives.  The  operations  specified  by  GPSS  coding  are 
executed  interpretively ;  i.e.,  GPSS  programs  are  not  compiled  or 
assembled,  but  are  examined  by  the  IBM  GPSS  program.  The  actions 
specified  by  the  user  coding  are  carried  out  under  control  of  this 
IBM  Program.  Execution  of  GPSS  simulations,  therefore,  always  requires 
submission  of  a  source  deck  (the  only  object  program  is  that  supplied 
by  IBM).  The  interpretive  execution  of  this  source  deck  usually 
requires  more  computation  time  than  would  be  required  by  simulation 
languages  which  do  not  operate  interpretively.  Also,  this  contributes 
to  GPSS  core  storage  requirements,  which  are  generally  in  excess  of 
the  alternatives.  The  data  structures  offered  by  GPSS  are  not  as 
powerful  as  those  available  in  many  other  simulation  languages. 

Since  simulation  is  performed  by  the  time-phased  alteration  of  set 
relationships,  this  disadvantage  to  GPSS  can  become  important  when 
the  modeling  requirements  become  complex. 

GPSS,  therefore,  permits  the  rapid  development  of  a  simulation 
capability  from  negligible  beginnings;  it  facilitates  the  generation 
of  workable  programs  (and  hence  answers)  in  minimum  elapsed  time, 
and  it  provides  a  common  standard  language  which  can  be  used  by  a 
large  number  of  machines  and  personnel.  It  is,  however,  somewhat 
inefficient,  cumbersome,  and  rigid. 
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GSP  -  General  Simulation  .Program 


1.  Background  Information 
Author:  K.  D.  Tocher 

Originating  Organization:  United  Steel,  Ltd. 

Date  of  Release:  1960 

Current  Status:  GSP  MK  II 

Machine  Implementation:  Ferranti  Pegasus 

Elliott  503 


2.  Major  Features 

GSP  represents  one  of  the  pioneering  works  on  simulation  languages. 
It  is  tersely  written  and  intended  primarily  for  mathematically-oriented 
users. 

Particularly  designed  for  the  simulation  of  systems  found  in 
manufacturing  plants,  the  structure  consists  of  representing  the 
system  as  a  collection  of  machines  in  various  states.  The  definition 
of  a  machine  may  encompass  any  system  entity.  To  this  extent,  GSP 
is  considered  a  "machine-based  language";  i.e.,  emphasis  is  placed 
on  activities  executed  b£  entities.  Formulation  of  the  model  consists 
of  defining  the  set  of  machines,  the  initial  conditions,  rules  gov¬ 
erning  their  operation,  and  a  description  of  the  actions  which  they 
perform. 

The  descriptive  unit  of  GSP  is  called  an  activity;  each  execution 
of  an  activity  constitutes  an  event;  i.e.,  a  change  in  the  state  of 
a  machine.  The  user  defines  the  necessary  states  of  machines  for 
activities  to  commence,  and  the  conclusion  is  determined  probabilis¬ 
tically. 

The  scheduling  of  a  machine  to  its  next  activity  is  referred  to 
as  engaging  the  machine.  Machines  are  considered  to  be  either 
committed  or  available,  and  their  status  may  be  interrogated. 
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Activities  are  categorized  as: 

a.  B-activity  -  A  bound  activity  consists  of  a  set  of  state¬ 
ments  which  describe  the  changes  to  be  made  in  the  state  of  the  plant 
when  a  machine  becomes  available. 

b.  C-activity  -  In  addition  to  a  delineation  of  the  state 
changes,  a  conditional  activity  consists  of  a  set  of  statements  which 
specify  the  circumstances  under  which  it  may  occur. 

GSP  is  principally  an  activity-oriented  language,  but  it  employs 
both  activity  scan  and  event-selection  in  its  control  algorithm.  It 
operates  in  a  three  phase  manner: 

a.  Phase  A  -  Scans  the  list  of  engaged  machines  and  advances 
the  clock  time  to  the  earliest  time  of  machine  availability. 

b.  Phase  B  -  Bound  activities  associated  with  available  machines 
are  executed. 

c.  Phase  C  -  Scans  list  of  conditional  activities  and  performs 
all  possible  state  changes. 

Both  references  present  the  language  specifications  in  a  level 
of  detail  beyond  the  scope  of  this  paper.  Reference  2  deals  with  MK 
II,  the  revised  version  of  GSP.  Advanced  language  features  are  dis¬ 
cussed  with  reference  to  MK  I,  MONTECODE,  SIMSCRIPT,  CSL  and  RSP.^ 

In  summary,  MK  II  eliminates  the  restrictions  of  the  MK  I  version  by 
providing  more  sophisticated  techniques  for  activity  selection,  set 
manipulation,  monitoring  facilities,  sampling  procedures  and  report 
generation. 


References 
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Recursive  Simulation  Program  is  an  interim  program  wit1^  limited 
facilities  which  reduces  a  simulation  to  a  recursive  calculation  in 
order  to  obtain  a  rapid  appraisal  of  system  behavior.  A  more  compre¬ 
hensive  program  is  in  preparation. 
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MILITRAN 


1.  Background  Information 

Author:  Shapiro 

Originating  Organization:  Systems  Research  Group,  Inc. 

Date  of  Release:  1964 

Current  Status:  Obsolete 

Machine  Implementation:  IBM  7090/7094 

2.  Major  Features 

Although  MILITRAN  is  considered  obsolete,  it  is  included  in  this 
compendium  for  historical  reasons.  It  is  a  general  purpose,  problem- 
oriented  language  which  was  designed  to  facilitate  the  simulation  of 
military  systems.  The  development  of  the  language  was  jointly  spon¬ 
sored  by  the  Office  of  Naval  Research  and  the  Air  Force  Systems  Command 
(ESD) . 

Its  special  features  include  object  modes,  list  processing  state¬ 
ments,  event  processing  procedures,  special  retrieval  arrays,  etc. 

The  basic  elements  in  the  language  consist  of  individual  objects, 
object  types  and  object  classes.  The  essence  of  simulation  consists 
in  maintaining  the  status  and  interaction  of  the  participating  objects 
by  the  processing  of  events.  An  event  is  categorized  by  time  of 
occurrence,  participating  objects,  necessary  conditions,  and  asso¬ 
ciated  processing.  MILITRAN  classifies  events  as  permanent  and 
contingent.  They  differ  in  the  manner  of  occurrence;  permanent 
events  perform  activities  which  cannot  be  readily  scheduled  but  occur 
at  periodic  intervals,  while  contingent  events  occur  at  a  critical 
juncture  in  time  and  are  scheduled  when  circumstances  dictate. 

The  CONTINGENT  EVENT  statement  fulfills  the  following  functions: 

1.  Defines  an  event  type. 

2.  Associates  with  the  event  a  list  of  potential  event 
occurrences,  each  of  which  has  the  following  parameters: 
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scheduled-event  time 


P2  -  attacking  object 
-  target  object 


P 


1 


►  Optional 


3.  Delineates  the  program  steps  representative  of  the 
occurrence  of  the  event. 


The  potential  events  are  generated  dynamically  as  the  simulation 
progresses  through  time.  Thus,  at  any  point  in  the  simulation  the  set 
of  future  potential  events  is  defined  by  the  set  of  all  entries  on 
CONTINGENT  EVENT  lists.  A  PERMANENT  EVENT  does  not  necessarily 
require  a  list. 

The  NEXT  EVENT  statement  is  used  to  start  the  event  processing 
and  to  maintain  the  proper  chronological  sequencing.  Permanent  events, 
if  they  exist,  are  executed  in  sequence  and  always  precede  every  con¬ 
tingent  event.  After  the  completion  of  this  phase  the  contingent 
event  list  is  scanned  (either  in  its  entirety  or  a  specified  subset 
thereof),  and  the  event  with  the  minimum  time  component  on  its  list 
is  selected  for  processing. 


Reference 

"MILITRAN  Programming  Manual,"  Systems  Research  Group,  Inc.,  ESD 
Report  ESD-TDR-64-320. 
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MONTECODE 


1 .  Background 

Authors:  D.  H.  Kelley 
J.  N.  Buxton 

Originating  Organization;  British  Iron  and  Steel  Research 

Association  (BISRA) ,  United  Kingdom 

Date  of  Release:  1959 

Status:  Unknown 

Machine  Implementation:  Ferranti  Pegasus  I 

2.  Major  Features 

Montecode,  one  of  the  first  simulation  languages,  was  developed 
in  England  in  1959.  Many  of  the  later  languages  represent  an  exten¬ 
sion  of  the  basic  concepts  of  Montecode.  It  is  an  interpretive 
language  and  was  developed  as  a  means  of  expediting  the  Monte  Carlo 
simulation  of  industrial  scheduling  problems.  The  basic  language 
features  of  Montecode  are  similar  in  many  respects  to  those  of 
Autocode. 

The  distinguishing  feature  of  Monte  Carlo  simulations  is  that 
probability  distributions  are  used  to  determine  the  inter-arrival 
and  service  times  of  each  independent  variable.  Montecode  provides 
for  the  random  sampling  from  distributions,  the  maintenance  of  queues, 
sequencing  of  events  based  on  the  critical  event  principle,  and  the 
presentation  of  results  in  histogram  form. 

The  controlling  elements  in  the  simulation  are  defined  as  the 
"action  times."  Each  action  time  is  associated  with  an  event  and 
indicates  the  time,  relative  to  current  simulation  time,  when  the 
event  will  next  occur.  When  the  action  time  becomes  zero,  the  event 
"occurs";  i.e.,  a  programmed  subroutine  is  executed. 


Reference 

D.  H.  Kelley  and  J.  N.  Buxton,  "Montecode  -  An  Interpretive  Program 
for  Monte  Carlo  Simulation,"  Computer  Journal,  July  1962,  pp .  88-93. 
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NSS  -  New  Simulation  jSystem 


1.  Background  Information 

Authors:  K.  R.  Blake 

G.  P.  Blunden 

K.  S.  Krasnow 

B .  M.  Leavenworth 

L.  J.  Parente 
S.  C.  Pierce 

Originating  Organization:  IBM  Corp. ,  Advanced  Systems 

Development  Division 

Date  of  Release:  Not  released 

Status:  IBM  Proprietary 

Machine  Implementation:  A  prototype  processor  currently 

being  implemented 


2 .  Maj  or  Features 

NSS  is  an  experimental  language  which  was  designed  for  use  in 
the  representation  and  simulation  of  systems  with  a  high  degree  of 
interaction  and  parallelism;  the  authors  consider  multiprocessing 
to  be  a  representative  example.  Additionally,  the  language  incor¬ 
porates  features  which  easily  accommodate  the  experimental  nature 
of  simulation  studies* 

The  language  is  process-oriented;  and  although  patterned  after 
PL/I,  it  is  based  on  its  own  data  and  program  structures. 

In  the  context  of  this  language,  an  entity  is  any  system  com¬ 
ponent,  static  or  dynamic,  that  can  be  modified,  categorized  or 
observed.  By  this  definition,  sets  and  processes  are  classified  as 
entities.  The  characteristics  of  an  entity  are  described  by  attri¬ 
butes  whose  values,  taken  in  the  aggregate,  completely  define  the 
current  state  of  the  system. 

As  previously  stated  the  unifying  concept  of  the  language 
classifies  a  process  as  an  entity.  A  process  is  defined  as  an 
entity  that  exists  over  time  and  possesses  dynamic  chai^cteristics 
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that  render  it  capable  of  altering  the  system  state  (such  as  creating  and 
destroying  entities,  altering  set  membership,  modifying  the  state  of 
an  entity  and  affecting  interactions  in  the  system)  on  the  basis  of 
complex  logical  decisions.  As  such,  a  process  is  not  completely 
specified  by  its  associated  attributes  and  must  be  defined  in  terms 
of  its  behavior  pattern.  Each  type  of  system  process  is  defined  in 
terms  of  its  behavior  pattern,  and  the  system  dynamics  are  completely 
defined  by  the  set  of  all  behavior  patterns.  The  Component  descrip¬ 
tion"  section  of  the  model  identifies  and  specifies  the  attributes 
of  each  system  entity;  the  "behavior  description"  section  specifies 
the  behavior  patterns  for  all  process  types.  A  process  is  similar 
to  a  static  entity  in  that  it  is  a  system  component,  possessing 
attributes  and  capable  of  being  modified  and  observed;  it  differs 
in  that  it  produces  change.  A  static  entity  may  be  conceptualized 
as  a  data  carrier  that  does  nothing. 

Entities  and  processes  may  be  defined  whose  behavior  is  related 
solely  to  the  experimental  aspects  of  the  simulation  study;  no  dis¬ 
tinction  is  made  between  these  and  model  entities.  Representative 
of  these  are  facilities  for  specifying  initialization  and  environ¬ 
mental  conditions,  defining  processes  which  monitor  and  measure 
system  entities,  analyze  the  data  and  provide  output  reports. 

The  statements  of  a  process  may  be  organized  into  blocks  that 
are  executed  in  line  or  into  FUNCTIONS  which  are  accessed  in  the 
manner  of  a  subroutine.  Functions  are  recursive,  and  the  arguments 
may  take  the  form  of  an  expression  or  a  reference  to  any  attribute. 

The  value  of.  an  attribute  may  be  the  name  of  another  entity. 

This  dynamic  referencing  capability  allows  for  the  definition  of 
complex  relationships  between  entities  and  facilitates  the  con¬ 
struction  of  generalized  program  modules. 

Interaction  within  and  between  processes  may  occur  in  either 
a  time-dependent  or  state-dependent  manner;  the  sequencing  algorithm 
provides  the  control  necessary  to  allow  for  the  simulation  of  parallel 
processes  on  a  sequential  machine. 

A  macro  facility  provides  for  the  definition  of  new  processes  in 
terms  of  those  already  defined,  thereby  extending  the  language  and 
allowing  it  to  be  organized  for  the  simulation  of  specialized  classes 
of  problems. 

In  conclusion,  the  language  attempts  to  provide  a  simpler 
conceptual  framework  and  advanced  experimental  capability. 
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OPS-3/OPS-4 


1.  Background  Information 

Authors:  Martin  Greenberger 
Malcolm  M.  Jones 
James  H.  Morris,  Jr. 

David  N.  Ness 

Originating  Organization:  Massachusetts  Institute  of  Technology 

Date  of  Release:  1965 

Status:  OPS-3  current 

OPS-4  specified  but  not  programmed 

Machine  Implementation:  OPS-3  Modified  IBM  7094  (CTSS) 

OPS-4  GE  645 


2.  Major  Features 

OPS-3  is  a  simulation  language  which  was  designed  to  extend  the 
facilities  of  the  Compatable  Time-Sharing  System  (CTSS)  to  allow  for 
on-line  programming  and  model  building. 

On-line  facilities  allow  the  user  to  interact  with  the  computer 
and  to  build,  modify,  test,  and  run  simulations  in  an  incremental 
and  repetitious  manner  and  also  to  incorporate  into  the  simulation 
the  actual  phenomenon  being  simulated.  This  mode  of  simulation 
dictates  a  specially  designed  simulation  language  and  represents 
the  rationale  for  the  development  of  OPS-3. • 

OPS-3  is  characterized  by  the  following  features: 

a.  Easy  to  modify  model  structure  without  recompilation 
or  reloading. 

b.  Data  structures  are  specified  and  initialized 
dynamically. 

c.  Complete  or  partial  reinitialization  of  the  model  is 
possible. 
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d.  Scheduling  mechanism,  called  the  AGENDA,  is  accessible 
to  the  user. 

e.  Comprehensive  tracing  and  debugging  facilities  are 
provided. 

f.  General  algebraic  language  is  available. 

g.  Linkage  with  subroutines  written  in  any  language  is 
provided  for. 

The  installation  of  a  new  time-sharing  system  called  MULTICS 
provided  the  impetus  to  redesign  OPS-3,  to  correct  its  deficiencies, 
and  to  make  optimum  utilization  of  the  more  powerful  features  of  the 
new  system.  OPS-3  is  an  interpretive  language  and,  therefore,  exe¬ 
cution  is  slow;  it  has  limited  data  entities  and  statistics  gathering 
routines  and  an  awkward  syntactical  structure. 

OPS-4  exists  only  as  a  set  of  specifications  and  has  not  been 
programmed.  Since  on-line  simulation  appears  to  be  a  future  trend 
in  computer  simulations,  the  more  important  features  of  the  language 
will  be  briefly  discussed. 

MULTICS,  implemented  on  the  GE  645,  employs  paging  techniques 
and  allows  multiple  users  to  access  the  same  program  simultaneously 
while  maintaining  unique  data  segments. 

The  language  OPS-4  is  a  subset  of  PL/1  from  which  it  derives  its 
basic  algebraic  and  data  handling  capability.  Special  simulation 
features  as  well  as  specialized  data  types  (sets,  queues,  and  tables) 
have  been  incorporated.  It  encompasses  the  features  of  both  event 
and  activity  oriented  languages;  events  may  be  scheduled  directly  as 
in  SIMSCRIPT  or  implicitly  as  in  SOL.  The  structure  of  OPS-4  is 
organized  such  that  an  activity  is  described  by  a  program  which  may 
encompass  multiple  events.  The  execution  of  an  activity  or  an  event 
may  be  conditional  or  time-dependent.  Activities  are  independently 
compiled  and  are  written  as  external  procedures  which  have  local 
data  bases  and  may  selectively  share  data  bases  with  other  activities. 
Since  the  computer  has  a  multiprocessor  capability,  each  activity 
declaration  must  include  a  specification  for  sequential  or  simul¬ 
taneous  operation.  The  multiprocessor  capabilities  are  limited  and 
in  no  way  negate  the  need  for  sequencing  algorithms  to  model  simul¬ 
taneous  events.  The  multiprocessor  capabilities  are  of  value  in 
performing  functions  which  do  not  affect  the  course  of  the  simulation, 
such  as  user  interaction,  debugging  monitors,  statistical  processing, 
etc. 


39 


The  design  of  the  language  has  been  predicated  on  the  philosophy 
that  a  simulation  is  repetitive  and  experimental  in  nature.  The 
language,  therefore,  has  features  which  allow  for  the  incremental 
design  and  testing  of  a  model.  The  user  may  interrupt  the  model 
during  execution,  redirect  the  sequence  and  execution  of  events  and, 
if  desired  later,  restore  the  model  to  its  initial  state  and  continue 
the  simulation  from  the  point  of  interruption. 


References 
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QUIKSIM 


1.  Background  Information 

Author:  David  G.  Wearier 

Originating  Organization:  National  Cash  Register  Company 

Date  of  Release:  NCR  proprietary 

Status:  To  be  reprogrammed  for  NCR  Century  series 

Machine  Implementation:  NCR  315  RMC 

2.  Major  Features 

QUIKSIM,  a  block  structured  language  written  in  SIMSCRIPT, 
represents  an  attempt  to  incorporate  the  best  features  of  block 
type  and  algebraic  languages  into  a  general  purpose  simulation 
language.  SIMSCRIPT,  itself  a  high  level  simulation  language,  has 
been  used  to  produce  an  interpreter  for  QUIKSIM,  an  even  higher 
level  language.  QUIKSIM  is,  therefore,  a  block-structured,  inter¬ 
pretive  language. 

In  QUIKSIM  the  simulated  system  is  described  by  a  sequence  of 
block  types,  representative  of  the  system  logic,  called  an  application. 
Transactions  called  jobs  flow  through  the  application  executing  the 
blocks.  The  system  is  also  comprised  of  entities  which  are  used  to 
analyze  the  system  traffic;  representative  of  such  are: 

a.  processing  entities  -  facilities,  storages,  and  switches 

b.  data  collection  entities  -  tables 

c.  computational  entities  -  functions 

Each  block  and  entity  are  represented  internally  by  a  temporary  data 
record,  linked  together  by  filing  them  in  lists.  Memory  is  dynamically 
allocated,  and  it  is  possible  to  insert  new  blocks  during  program 
execution. 

The  QUIKSIM  interpreter  consists  of  three  major  routines: 

a.  Input  and  set  up  routine  which  reads  in  the  input,  sets 
up  temporary  entities,  and  files  them  in  lists. 
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b.  A  driver  routine  which  controls  the  flow  of  a  job 
through  an  application. 

c.  A  SIMSCRIPT  driver  which  is  a  simulated  time  clock 
and  drives  the  system  from  event  to  event. 

The  interpreter  allows  for  modularity  in  the  block  structure,  and 
although  QUIKSIM  contains  27  block  types  to  perform  the  major  functions 
of  simulation,  block  routines  written  by  the  user  in  either  SIMSCRIPT 
or  FORTRAN  may  be  incorporated  without  restriction. 

While  no  attempt  will  be  made  here  to  explain  the  functions  of 
all  the  standard  block  types,  a  few  of  the  salient  features  should 
be  noted: 


a.  Processing  entities  may  be  grouped  into  classes  to  facilitate 
the  searching  of  lists. 

b.  Sequences  of  blocks  may  be  executed  like  subroutines. 

c.  The  capability  of  generating  jobs  facilitates  the  simulation 
of  parallel  processing. 

d.  QUIKSIM  assumes  each  processing  entity  has  its  own  queue 
and  provides  for  automatic  queue  management. 

e.  The  need  to  simulate  the  transmission  of  signals  in  computer 
simulation  models  was  responsible  for  the  definition  of  two 
block  types. 

3.  Application 

Included  in  the  reference  as  an  illustration  of  the  features  of 
the  language  is  an  example  of  a  remote-terminal  communications  system 
operating  under  a  polling  discipline. 


Reference 
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Written  in  SIMSCRIPT,11  Proceedings  of  Third  Conference  on  Application 
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SIMON  II 


1.  Background  Information 
Author:  P.  R.  Hills 

Originating  Organization:  Bristol  College  of  Science  and 

Technology,  England 

Date  of  Release:  1965 
Status :  Current 

Machine  Implementation:  Elliott  503  and  803 

Any  Machine  With  ALGOL  Compiler 


2.  Major  Features 

SIMON,  which  Is  In  the  form  of  a  set  of  ALGOL  procedures.  Is 
an  activity-oriented  language  designed  for  writing  simulation  programs 
based  on  the  Tocher  model.  This  model  consists  of  a  series  of  machines 
or  entitles,  the  state  of  which  at  any  given  point  In  time  will  com¬ 
pletely  define  the  state  of  the  system. 

Provision  Is  made  for  grouping  entitles  with  common  attributes 
Into  sets.  Since  position  Is  maintained  within  the  set.  It  has  the 
properties  of  an  ordered  queue. 

At  any  point  In  time  the  model  machines  are  either  In  a  time- 
dependent  active  state  or  a  time-independent  Idle  state.  Time  is 
advanced  in  discrete  stages  to  the  next  most  Imminent  event.  To 
facilitate  the  sequencing  control,  the  names  of  all  machines  In  a 
time-dependent  state  are  preserved  In  a  list  called  "tlmeset." 

Initialization  of  the  program  consists  of  input  specifying  the 
entities,  their  associated  attributes  and  processing  type,  the  sets, 
distributional  data,  and  the  Initial  starting  conditions. 

The  program  control  consists  of  three  phases: 

A  Phase  -  Advances  simulation  time  to  the  minimum  non-zero 
time  as  recorded  In  tlmeset  and  transfers  the 
identity  of  the  associated  machine  to  Phase  B. 
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B  Phase  -  Contains  the  disengaging  instructions  to  change  the 
status  of  the  machine  from  time-dependent  to  time- 
independent  . 

C  Phase  -  Contains  the  engaging  instructions.  An  iterative 

procedure  is  executed  in  Phase  C  which  tests  conditions 
and  sets  up  all  possible  new  time-dependent  states. 
Control  is  then  transferred  back  to  Phase  A. 


Reference 

P.  R.  Hills,  "SIMON  -  A  Computer  Simulation  Language  in  ALGOL,"  in 
S.  H.  Hollingdale,  ed. ,  Digital  Simulation  in  Operational  Research, 
American  Elsevier  Publishing  Company,  Inc.,  New  York,  1967,  pp.  105-115. 
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SIMPAC  -  Simulation  Package 


1.  Background  Information 

Authors:  M.  R.  Lachner 
J.  Kagdls 

Originating  Organization:  System  Development  Corporation 

Date  of  Release:  1961 

Current  Status:  Obsolete 

Machine  Implementation:  IBM  7090 

2.  Major  Features 

SIMPAC  is  a  simulation  package  developed  to  simulate  waiting 
line  and  scheduling  problems,  but  it  has  had  limited  use  outside  of 
SDC  where  it  was  developed.  It  is  considered  to  be  a  package  in 
that  it  provides: 

a.  Modeling  concepts  for  describing  the  model. 

b.  A  language  to  generate  computer  code. 

c.  A  program  to  move  the  simulation  through  time  and  record 
performance. 

d.  An  output  presentation  capability. 

The  basic  modeling  concepts  are  predicated  on  the  world  view 
that  a  system  is  a  complex  of  activities,  activity  performers, 
transient  information  records,  and  queues.  Each  activity  is  described 
by  an  algorithm  which  delineates  the  necessary  conditions  for  the  set 
up  phase  and  the  program  steps  descriptive  of  the  execution  phase. 
Performance  of  an  activity  is  contingent  upon  the  availability  of 
both  the  activity  performers  and  the  required  information.  Each 
component  of  the  model  has  an  associated  control  block  which  main¬ 
tains  data  such  as  addresses,  current  status,  and  time  and  utilization 
statistics. 
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The  simulation  model  is  comprised  of  symbolic  expressions  in 
combination  with  SIMP AC  macro  expressions.  The  basic  SIMP AC  program 
consists  of  sixty  subroutines  whose  functions  include: 

a.  Initialization  and  generation  of  exogenous  events 

b.  Clock  time  keeping 

c.  Queue  manipulation 

d.  Associative  storage  control 

e.  Data  recording 

f.  Data  analysis  and  output  presentation 

g.  Distribution  sampling 

h.  Mathematical  functions 

SIMPAC  is  atypical  in  that  it  utilizes  a  fixed  increment  time 
mechanism.  The  time  increment  may  be  varied  or  made  a  function  of 
the  state  of  the  model.  A  cycling  routine  continually  executes  the 
set  of  algorithms  and  during  each  cycle  moves  each  component  forward 
in  time  by  the  specified  amount.  The  control  block  associated  with 
each  activity  records  the  performance  time  to  date  and  the  performance 
time  necessary  for  completion. 


Reference 

Michael  R.  Lachner,  "Toward  A  General  Simulation  Capability," 
Proceedings  of  Western  Joint  Computer  Conference,  1962,  pp.  1-14. 
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SIMPLE  -  Simulation  Program  Language^ 


1.  Background  Information 

Authors:  J.  J.  Donovan 
M.  M.  Jones 
J.  W.  Alsop 

Originating  Organization:  Massachusetts  Institute  of  Technology, 

Project  MAC 

Date  of  Release:  Not  released 
Status :  Experimental 

Machine  Implementation:  MULTICS  Time  Sharing  System  (M.I.T.) 

IBM  1130 


2.  Major  Features 

SIMPLE  is  an  interactive  on-line  simulation  system  that  incor¬ 
porates  facilities  for  graphical  display*  The  language  is  imbedded 
in  PL/I;  and  while  some  of  the  simulation  features  are  integrated 
into  the  language,  others  are  implemented  as  external  routines. 

This  organization  allows  for  the  inclusion  in  the  language  of  both 
the  transaction-oriented  approach  of  GPSS  and  the  activity-oriented 
approach  of  SIMULA. 

The  language  provides  extensive  facilities  for  the  user  to 
interact  with  the  system,  to  describe  and  display  the  topology  of 
the  system  in  hierarchical  levels  of  detail,  to  display  time-series 
plots  and  frequency  distributions,  and  to  validate  the  system  in 
real  time. 

These  features  are  representative  of  new  trends  in  the  design 
of  simulation  languages. 

3.  Applications 

The  applicability  of  the  real  time  feature  of  the  system  to  the 
simulation  of  computer  systems  on  the  micro  logic  level  is  dependent 
upon  the  ability  of  the  host  computer  to  keep  pace  with  real  time. 
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SIMSCRIPT 


1.  Background  Information 

Authors/Originating  Organization/Date  of  Release: 

SIMSCRIPT  I 

H.  M.  Markowitz,  B.  Hausner  and  H.  W.  Karr/ 

The  RAND  Corporation/1963 

SIMSCRIPT  1.5 

H.  W.  Karr,  H.  Kleine  and  H.  M.  Markowitz/ 

California  Analysis  Center,  Inc./1966 

SIMSCRIPT  II 

H.  M.  Markowitz,  B.  Hausner,  P.  J.  Kiviat  and  R.  Villanueva/ 
The  RAND  Corporation/1968 

SIMSCRIPT  II  Plus 

P.  J.  Kiviat /Simulation  Associates,  Inc./1970 

Machine  Implementation: 

SIMSCRIPT  I 

IBM  7040/44,  7090/94 

SIMSCRIPT  1.5 

IBM  7040/44,  7090/94 
CDC  3600/3800/6400/6600/6800 
Phil co  210/211/212 
UNIVAC  490/1107/1108 

GE  625/635  (implemented  by  Digitek,  Inc.) 

CDC  6400/6500/6600  (labeled  SIMSCRIPT  2.0) 

SIMSCRIPT  II 

IBM  360  (implemented  by  RAND  and  CAC) 

CDC  6400/6500/6600  (implemented  by  CAC) 
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SIMSCRIPT  II  PLUS 


IBM  360 

RCA  Spectra  70,  DOS 
2.  Major  Features 

SIMSCRIPT  is  a  versatile,  powerful,  and  efficient  simulation 
language  which,  through  several  improvements  since  its  inception  in 
1963,  has  kept  pace  with  (if  not  paced)  the  development  of  special 
languages  for  use  in  simulation.  Its  static  structure  is  based  upon 
entities  which  may  be  permanent  (lasting)  or  temporary  (created  and/ 
or  destroyed  during  the  simulation).  The  properties  of  entities  are 
denoted  by  associated  attributes.  Entities  may  be  grouped  together 
into  sets.  The  definition  of  an  entity  results  in  a  class  of  objects, 
each  possessing  the  same  list  of  attributes  and  the  same  list  of 
potential  set  memberships.  SIMSCRIPT  is  basically  event-oriented 
with  discrete  time  intervals  as  in  GPSS,  although  the  programmer  can 
perform  scheduling  directly  in  SIMSCRIPT  but  not  in  GPSS.  The  changes 
in  state  represented  by  events  are  accomplished  through  the  direct 
coding  of  event  routines  which  alter  data  interrelationships,  cause 
and  cancel  events,  and  transfer  control  either  to  the  scheduler  or 
to  another  event  routine.  Events  occur  in  zero  simulated  time  so 
that  activities  must  be  represented  as  a  sequence  of  events. 

SIMSCRIPT  I  programs  are  translated  into  FORTRAN  and  then 
compiled,  but  all  succeeding  versions  are  compiled  directly  into 
machine  code.  Hence,  SIMSCRIPT  I  accepts  coding  in  FORTRAN,  and 
other  versions  permit  machine  language  coding;  but  use  of  FORTRAN 
or  machine  language  limits  the  transferability  of  SIMSCRIPT  programs 
between  compilers  of  different  versions. 

SIMSCRIPT  1.5  provides  a  capability  almost  identical  to  its 
predecessor  with  rather  minor  syntax  changes  and  direct  compilation 
as  noted  above.  SIMSCRIPT  II  represents  a  major  departure  from 
previous  versions  since  it  is  designed  and  produced  as  a  general 
programming  language.  It  can  be  used  for  such  widely  varying  pur¬ 
poses  as  business  data  processing,  scientific  programming,  list 
processing,  and  through  special  purpose  features,  simulation.  The 
language  structure  and  syntax  employed  differ  significantly  from  its 
predecessors,  and  a  translator  planned  to  provide  forward  compatibility 
(SIMSIFT)  was  never  produced.  Programs  written  in  SIMSCRIPT  I  or  1.5, 
therefore,  cannot  be  run  with  SIMSCRIPT  II.  The  newest  version, 
SIMSCRIPT  II  Plus,  has  a  more  flexible  and  compact  data  structure 
and  better  diagnostics,  including  some  error  correction  (described 
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as  a  "large  percentage  of  user  syntax  errors"  )  which  is  used  to 
force  execution  of  every  complete  program.  It  is  also  faster  at 
program  assembly  than  SIMSCRIPT  II.  Execution  time  is  claimed  to  be 
20Z  faster  than  earlier  versions  of  SIMSCRIPT. 2  The  comments  which 
follow  apply  to  SIMSCRIPT  II,  though  many  apply  to  all  versions. 

The  language  is  described  in  terms  of  five  levels  which  are 
identified  as  follows. 


Level  1:  A  simple  teaching  language  designed  to  introduce 
programming  concepts  to  nonprogrammers. 

Level  2:  A  language  roughly  comparable  in  power  with 

FORTRAN  but  departing  greatly  from  it  in  specific 
features. 

Level  3:  A  language  roughly  comparable  in  power  to  ALGOL 

or  PL/l,  but  again  with  many  specific  differences. 


Level  4:  That  part  of  SIMSCRIPT  II  that  contains  the  entity  - 
attribute  -  set  features  of  SIMSCRIPT.  These 
features  have  been  updated  and  augmented  to  provide 
a  more  powerful  list  -  processing  capability.  This 
level  also  contains  a  number  of  new  data  types  and 
programming  features. 


Level  5:  The  simulation-oriented  part  of  SIMSCRIPT  II 

containing  statements  for  time  advance,  event¬ 
processing,  generation  of  statistical  variates, 
and  accumulation  and  analysis  of  simulation¬ 
generated  data. 


SIMSCRIPT  II  has  an  extended  timing  routine  which  permits 
activities  as  well  as  events  to  be  represented.  Output  reports  are 
produced  by  a  report  generator  which  utilizes  a  user-coded  sample 
report  for  input. 


^P.  J.  Kiviat,  promotional  pamphlet  from  Simulation  Associates,  Inc. 

2Ibid. 

3 

P.  J.  Kiviat,  et.  al.,  The  SIMSCRIPT  II  Programming  Language, 
Prentice  Hall,  Inc.,  Englewood  Cliffs,  New  Jersey,  1968,  p.  v. 
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3,  Applications 

SIMSCRIPT  applications  are  broad  and  extensive,  including 
analysis  of  the  operations  of  railroads,  canals,  warehouses, 
elevator  banks,  production  lines,  the  construction  of  computer 
systems,  and  procedures  for  aircraft  maintenance  and  supply.  The 
language  has  been  utilized  in  producing  a  model  called  Extendable 
Computer  System  Simulator  (ECSS)  referenced  elsewhere  in  this  docu¬ 
ment. 
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SIMTRAN 


1.  Background  Information 

Author:  C.  R.  Dowling 

Originating  Organization:  International  Business  Machines 

Corporation 

Date  of  Release:  1965 

Status:  Obsolete 

Machine  Implementation:  IBM  7030 

2.  Major  Features 

A  modified  version  of  SIMSCRIPT  written  especially  for  the 
IBM  7030. 


Reference 

D.  M.  Braddock,  C.  R.  Dowling,  K.  Rochelson,  "SIMTRAN  -  A  Simulation 
Programming  System  for  the  IBM  7030,"  IBM  SDD,  Poughkeepsie,  N.  Y., 
July  1965. 


53 


SIMULA  -  Simulation  Language 


1.  Background  Information 

Authors :  Ole-Johan  Dahl 
Kristen  Nygaard 

Originating  Organization:  Norwegian  Computing  Center,  Oslo, 

Norway,  under  contract  with  The 
Sperry  Rand  Corporation,  Univac 
Division 

Date  of  Release:  1965 

Status:  Current 

Machine  Implementation:  Univac  1107 

2.  Major  Features 

SIMULA,  an  ALGOL  based,  process  oriented  simulation  language, 
was  designed  to  provide  facilities  for  the  formal  description  and 
simulation  of  discrete  event  systems.  It  includes  ALGOL  60  as  a 
subset  and  provides  the  mechanisms  for  extensive  list  processing, 
quasi-parallel  processing,  sampling  from  distribution  functions, 
and  accumulating  system  time  integrals  and  histograms. 

A  process-oriented  language  describes  a  discrete  event  system 
as  a  collection  of  modules  called  processes  which  specify  the 
behavior  of  the  system  components  and  may  be  conceptualized  as 
operating  in  parallel.  The  actions  and  interactions  of  the  pro¬ 
cesses  completely  define  the  behavior  of  the  system  as  the  simula¬ 
tion  progresses  through  time. 

For  the  sake  of  clarity,  some  SIMULA  terminology  is  defined: 

a.  Activity  declaration  —  the  description  of  a  process 
in  terms  of  data  declarations  and  operation  rules 
(i.e.,  sequences  of  state  changes). 

b.  Activity  —  a  class  of  processes  described  by  the 
same  declaration. 
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c.  Process  —  one  dynamic  instance  of  an  activity  declara¬ 
tion. 

d.  Event  —  active  state  of  a  process.  The  associated 
system  time  remains  constant  during  the  execution  of 
an  event. 

e.  Interaction  point  —  a  point  within  an  activity 
declaration  at  which  control  may  pass  to  another 
process . 

f.  Reactivation  point  —  a  point  within  a  process  where 
processing  is  to  resume  during  the  next  active  state. 

Each  process  is,  therefore,  one  instance  of  an  activity  (i.e.,  it 
has  a  unique  set  of  data  values  and  maintains  its  own  identity  as  it 
executes  the  behavior  pattern).  A  process  may  span  one  or  more 
interaction  points  at  which  time  it  passes  from  an  active  to  a 
non-active  state  and  control  is  surrendered  to  another  process.  The 
sequence  of  operations  in  the  system  may  be  defined  by  the  active 
states  of  its  component  processes.  This  mode  of  operation  in 
conjunction  with  the  appropriate  time  control  mechanism  has  been 
termed  quasi-parallel. 

The  dynamic  occurrence  of  events  in  a  SIMULA  model  is  con¬ 
trolled  via  scheduling  and  sequencing  statements  and  by  a  scheduling 
entity  called  an  event  notice.  An  event  notice  records  the  scheduled 
time  of  the  next  active  phase  (i.e.,  event)  of  a  referenced  process. 
The  set  of  event  notices  is  termed  the  sequencing  set  and  is 
arranged  in  order  by  the  value  of  the  time  references.  The  first 
member  is  representative  of  the  current  system  time  and  the 
currently  active  process.  At  the  completion  of  its  active  phase, 
the  event  notice  is  deleted  and  control  is  transferred  to  the 
reactivation  point  of  the  process  referenced  by  the  next  sequential 
event  notice. 

At  any  point  in  time  a  process  may  exist  in  one  of  four 
possible  states: 

a.  Active  —  Process  is  currently  active  and  via  sequencing 
statements  may  alter  the  state  of  any  process  including 
its  own. 

b.  Suspended  —  A  suspended  process  has  an  associated  event 
notice  and  a  reactivation  point. 
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c.  Passive  —  A  passive  process  has  a  reactivation  point, 
but  no  associated  event  notice. 

d.  Terminated  —  No  further  events  may  occur  in  association 
with  this  process;  it  consequently  has  neither  an  event 
notice  nor  a  reactivation  point. 
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SIMULA  67 


1.  Background  Information 

Authors:  0.  J.  Dahl 
B .  Myhrhaug 
K.  Nygaard 

Originating  Organization:  Norwegian  Computing  Center,  Oslo, 

Norway 

Date  of  Release:  Unknown 

Status :  Unknown 

Machine  Implementation:  Unknown 

2.  Major  Features 

SIMULA  67  is  a  general  purpose  programming  language  with  a 
built-in  simulation  capability.  Conceived  to  improve  the  facilities 
of  SIMULA  I  as  a  simulation  language,  it  evolved  into  a  general 
purpose  programming  language  and  finally  into  a  language  for 
generating  special  application  languages.  It  contains  ALGOL  60, 
with  minor  revisions,  as  a  subset. 

The  "object"  is  the  central  concept  in  SIMULA  67.  A  process 
class  declaration  (called  an  activity  declaration  in  SIMULA  I) 
defines  a  system  behavior  pattern  in  terms  of  the  associated  data 
and  actions.  An  object  is  a  self-contained  program  having  its  own 
local  data  and  executing  actions  as  defined  by  its  process  class 
declaration.  Objects  conforming  to  the  same  behavior  pattern  are 
considered  members  of  the  same  class.  Objects  are  manipulated  and 
related  to  each  other  by  list  processing  facilities.  As  in  SIMULA  I 
the  simulation  may  be  described  as  a  sequence  of  the  active  phases 
of  the  constituent  objects. 

SIMULA  67  may  be  used  as  a  language  for  generating  problem- 
oriented  languages  by  defining  a  class  containing  the  concepts 
necessary  for  the  special  application  area  and  adding  this  class  as 
a  prefix  to  the  program. 
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SIMULA  67  contains  a  class  called  "SIMULATION"  as  part  of  the 
language.  SIMULATION,  by  defining  a  time  axis  and  a  list  structure 
and  by  organizing  the  active  phases  of  an  object  through  the  time 
axis,  transforms  SIMULA  67  from  a  general  purpose  programming 
language  into  a  simulation  language.  This  same  technique  may  be 
utilized  to  generate  other  problem-oriented  languages. 


Reference 

0.  J.  Dahl,  B.  Myhrhaug,  and  K.  Nygaard ,  "Some  Features  of  the 
SIMULA  67  Language,"  Second  Conference  on  Applications  of  Simulation, 
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SOL  -  Simulation  Oriented  Language 


1.  Background  Information 

Authors:  D.  E.  Knuth 

J.  L.  McNeley 

Originating  Organization:  Burroughs  Corporation 

Case  Institute  of  Technology 

Date  of  Release:  1964 

Status:  Not  available  for  distribution.  Currently  being 

used  for  research  within  the  Burroughs  Corporation. 

Machine.  Implementation:  Burroughs  B5000/5500 

Univac  1107 


2.  Major  Features 

SOL  is  a  general  purpose  algorithmic  language  designed  for 
the  simulation  of  complex  systems.  It  incorporates  the  essential 
characteristics  of  GPSS  expressed  in  an  ALGOL-like  structure. 
Additionally,  SOL  provides  the  capability  of: 

a.  parallel  computation 

b.  arithmetic  expressions  incorporating  random  elements 

c.  automatic  generation  of  statistics 

The  descriptive  unit  in  SOL  is  called  a  "process.11  A  model  is 
conceptualized  as  a  program  consisting  of  a  number  of  individual 
processes  which  may  be  executed  in  parallel.  Provision  is  made  for 
both  intra-  and  inter-process  parallelism.  Objects  within  a  process 
have  been  defined  as  transactions,  and  each  has  an  associated  set  of 
local  variables  unique  to  the  process.  Interaction  between  pro¬ 
cesses  is  achieved  via  global  entities  and  control  statements. 

Global  entities  are  of  three  major  types:  variables,  facilities, 
and  stores.  Global  variables  may  be  accessed  for  reference  or 
change  by  any  transaction  in  the  system.  A  facility  is  a  global 
element  which  is  controlled  by  a  single  transaction  at  any  point  in 
time.  Facilities  are  seized  on  a  priority  basis  througa  the  concept 
of  the  "control  strength"  of  the  requesting  transaction.  Interrupts 
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occur  and  may  be  nested  to  any  depth.  Stores  are  space-shared 
global  elements  which  are  assigned  on  a  first-come,  first-served 
basis  with  no  provision  for  preemption. 

Control  is  transferred  from  process  to  process  as  delays  are 
encountered  by  transactions  waiting  for  time  to  pass,  for  logical 
conditions  to  be  satisfied,  for  a  facility,  or  for  space  within  a 
store.  Time  is  advanced  in  variable  time  increments,  meaning  that 
after  all  transactions  have  been  processed  at  the  current  time, 
time  is  advanced  to  the  earliest  completion  time  for  a  wait  state¬ 
ment  . 


Operationally,  a  SOL  program  is  translated  by  the  compiler 
into  an  interpretive  pseudo-code  which  is  executed  by  the  interpreter 
to  produce  the  statistical  results  of  the  simulation. 

3.  Applications 

Included  in  the  first  reference  is  a  detailed  model  for  a 
multiple  online  console  system.  Included  is  the  complete  SOL 
program,  an  explanation  of  each  statement,  and  some  representative 
output  reports. 

It  is  the  opinion  of  the  authors  of  that  article  that  SOL  Is 
especially  advantageous  for  simulating  computer  systems  since  the 
language  lends  itself  readily  to  the  description  of  computer  work¬ 
loads  . 
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SOLPASS  -  Simulation  Oriented  Language  Programming  _and 
Stimulation  System 


1.  Background  Information 

Authors:  Donald  J.  Miller 

Harry  C.  Page 

Originating  Organizations:  International  Computer  Sciences,  Inc. 

USAECOM,  Fort  Monmouth 

Date  of  Release :  1968 

Status:  Current 

Machine.  Implementation:  Burroughs  B5500  Remote  Access  System 

2.  Major  Features 

SOLPASS  is  an  extension  of  SOL  developed  under  government  contract 
to  simulate  large-scale  communications  networks.  It  is,  however,  a 
general  purpose  simulation  language  of  wide-range  applicability  for 
both  discrete  and  continuous  simulations. 

The  language  was  implemented  in  ALGOL  and  a  complete  ALGOL  capa¬ 
bility  is  provided  as  a  subset  of  the  language.  Since  SOLPASS  operates 
with  virtual  memory,  the  number  of  transactions  simultaneously  in 
process  is  limited  by  disk  memory  and  not  core  storage.  The  use  of 
core  swapping  and  overlay  techniques  provide  the  capability  for  a 
virtually  unlimited  number  of  queueing  variables  and  simultaneous 
queues.  A  special  language  construct  called  a  "trunk"  was  added  to 
the  basic  language  to  facilitate  simulation  of  large  communications 
trunk  lines.  A  trunk,  like  a  store,  is  a  space-shared  variable  with 
a  discrete  capacity  but  possesses  the  characteristic  of  a  facility  in 
that  it  is  pre-emptable  on  a  priority  basis. 

The  SOLPASS  system  consists  of  the  following  basic  components: 

a.  A  compiler  which  generates  an  ALGOL  program  from  the  SOL 
source  program. 

b.  An  ALGOL  compiler  which  generates  object  code. 
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c.  A  simulation  control  module  which  includes  the  scheduling 
algorithms . 

d.  A  statistical  analysis  program. 

During  the  execution  phase  an  external  event  log  file  is  generated 
which  records  the  occurrence  of  each  event  and  the  pertinent  data 
relative  to  each  queueing  variable.  These  data  are  subject  to  post¬ 
simulation  statistical  analysis.  A  variety  of  options  for  graphical 
output  aid  in  the  presentation  of  the  simulation  results. 

The  efficient  utilization  of  the  system  is  enhanced  by  the  incor¬ 
poration  of  extensive  debugging  and  error  analysis  features.  In 
addition,  a  unique  capability  exists  to  run  a  model  until  steady 
state  is  reached,  perform  a  breakout,  and  then  run  a  series  of 
restarts  imposing  various  experimental  conditions  on  the  steady 
state  system. 

3.  Applications 

Most  of  the  experience  gained  with  the  system  is  in  the  area  of 
traffic  and  systems  simulations.  The  authors  state  that  SOLPASS  seems 
to  be  ideally  suited  to  traffic  studies  but  also  performs  very  well 
in  systems  simulations  applications.  The  following  systems  are  among 
those  types  of  systems  simulated: 

a.  Control  Systems 

b.  Computer  Systems 

c.  Communications  Systems 

d.  Transmission  Systems 


Reference 
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SPL  -  Simulation  Programming  Language 


1.  Background  Information 
Author:  Luigi  Petrone 

Originating  Organization:  Olivetti  General  Electric,  Milan, 

Italy 

Date  of  Release:  Not  Released 
Status :  Experimental 

Machine  Implementation:  Potentially  available  for  any  machine 

with  PL/ I  compiler 


2.  Major  Features 

SPL  was  designed  to  be  translated  into  PL/I  by  a  preprocessor 
written  in  PL/ I  and  is,  therefore,  said  to  be  completely  defined  on 
PL/I.  Two  defining  methods  are  presented.  Implementation  A, 
discussed  in  depth,  is  based  primarily  on  the  tasking  concept  of 
PL/I.  Implementation  B,  discussed  in  cursory  fashion,  is  based  on 
the  use  of  programmed  allocation  and,  in  particular,  on  the  based 
variables  concept . 

The  SPL  language  is  patterned  principally  on  the  concepts  of 
SIMULA  and  to  a  lesser  degree  on  those  of  SOL.  One  purpose  of  the 
language  was  an  attempt  to  construct  the  synchronizing  mechanism  of 
SIMULA  within  the  parallel  programming  capability  of  PL/I,  and  thus 
to  make  quasi-parallel  processing  a  particular  case  of  parallel 
processing. 

An  evaluation  of  SPL  language  features  must  be  predicated  on  an 
in-depth  knowledge  of  both  PL/I  and  SIMULA  and  will  not  be  attempted 
here . 


Reference 

Luigi  Petroni,  "On  A  Simulation  Language  Completely  Defined  Onto 
The  Programming  Language  PL/I,"  in  J.  N.  Buxton  ed. ,  Simulation 
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CSS  -  Computer  System  Simulator 


1.  Background  Information 

Author:  Unknown 

Originating  Organization:  International  Business  Machines  Corp. 

Date  of  Release:  Not  released 

Status:  IBM  proprietary 

Machine  Implementations: 

IBM  7040/7044 
IBM.  7090/7094 
IBM  360 

2.  Major  Features 

The  Computer  System  Simulator,  CSS,  provides  a  language  and  a 
structure  specifically  designed  for  modeling  computer  systems  to 
evaluate  their  performance.  The  language  adapts  many  of  the  tech¬ 
niques  of  GPSS  and  traces  its  evolution  to  the  inability  of  GPSS  to 
accomplish  this  specialized  application  efficiently. 

CSS  provides  the  capability  to  model  a  large  variety  of  com¬ 
puter  systems  in  varying  levels  of  detail.  The  basic  input  consists 
of  the  following  components: 

a.  statement  of  system  configuration 

b.  description  of  operating  programs 

c.  description  of  the  system  environment 

The  system  configuration  identifies  the  system  components  and 
specifies  such  associated  data  as  the  size  of  core  storage,  data 
transfer  rates  for  1/0  devices,  and  1/0  device/channel  connections. 
The  operational  characteristics  of  some  IBM  hardware  are  included 
in  the  model. 
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The  operating  programs  include  the  users*  applications  programs 
and  the  system  control  programs  which  perform  the  functions  of  task 
scheduling,  interrupt  handling,  etc.  Programs  of  each  type  must  be 
defined  in  terms  of  logic,  timing  information,  and  statistical 
requirements.  This  implies  that  the  user  must  have  a  complete  and 
comprehensive  understanding  of  the  monitor  routines  of  the  object 
operating  system. 

The  system  environment  is  implicit  in  both  of  the  previous 
specifications.  Input  message  rates,  job  streams,  and  task  genera¬ 
tion  are  explicitly  defined  in  the  environmental  section. 

The  simulator  automatically  provides  features  to  update  the 
clock,  maintain  lists  of  future  events,  generate  random  numbers  and 
perform  statistical  functions. 

From  the  input  specifications  the  CSS  program  assembles  a 
model,  generates  the  tasks,  and  operates  the  model  in  an  interpretive 
fashion  until  the  occurrence  of  a  user-specified  stopping  condition. 

The  output  report  provides  a  summary  of  the  run  statistics  and 
includes: 

a.  listing  of  the  input  specifications 

b.  utilization  of  all  units  of  equipment 

c.  statistics  on  all  system  queues 

d.  statistics  on  usage  of  system  resources 

e.  activity  statistics  (number  of  messages  generated/ terminal 
etc.) 

The  CSS  is  based  on  the  concept  that  computer  system  operation 
may  be  represented  by  the  interaction  of  three  basic  simulator 
elements:  equipment,  transient  data  units,  and  programs.  To  this 

end  the  CSS  entities  consist  of: 

a.  equipment  entities  -  processors,  channels,  control  units, 
tapes,  disks,  terminals,  etc. 

b.  transient  entities  -  messages,  tasks,  events,  etc. 

c.  programs  -  applications,  control,  and  environment 

d.  modeling  entities  -  clock,  queues,  polling  lists,  etc. 
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Associated  with  each  entity  is  a  set  of  attributes  describing 
its  characteristics.  The  state  of  the  system  at  any  point  in  time 
is  defined  by  the  attribute  values  of  the  system  entities. 

The  CSS  instruction  set  consists  of  40  instructions  which 
resemble  a  high-level  macro  language  and  may  be  classified  into 
eight  categories  of  related  usage: 

a.  processing  control 

b.  attribute  access 

c.  entity  control 

d.  branching  control 

e.  line  control 

f.  I/O  control 

g.  run  control 

h.  library  linkage 

The  user  may  build  his  own  set  of  macroinstructions  from  the 
basic  set  provided,  thereby  increasing  the  scope  of  the  language. 

3,  Applications 

The  CSS  does  not  optimize  the  system  design,  but  it  does 
provide  a  means  to  determine  the  extent  to  which  system  performance 
meets  desired  criteria.  The  CSS  was  designed  principally  to  model 
computer  installations  having  a  real  time  capability  and  is  most 
advantageous  when  analyzing  large  systems  where  the  interaction  of 
processing  and  I/O  is  to  be  studied. 

Examples  of  configurations  that  may  be  modeled  are: 

a.  single-processor  card  or  tape  systems 

b.  disk  systems 

c.  multiprocessor  systems 

d.  teleprocessing  systems 
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Representative  types  of  operation  that  may  be  modeled  are: 


a. 

sequential 

b. 

multiprogram 

c. 

real-time 

d. 

time-sharing 

The 

attempt 

system. 

correct 

routines 

vehicle 

study  by  P.  H.  Seaman  and  R.  S.  Soucy  was  undertaken  in  < 
to  provide  a  general  submodel  of  the  SYSTEM/ 360  operating 
The  provision  of  such  a  submodel  assures  the  user  of  the 
logic  and  timings  of  the  supervisor  and  data  management 
.  Additionally,  it  provides  OS/ 360  developers  with  a 
to  test  proposed  changes: 

Reference 
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ECSS  -  An  Extendable  Computer  System  ^Simulator 


1.  Background  Information 

Author:  N.  R.  Nielsen 

Originating  Organization:  The  research  for  ECSS  was  sponsored 

by  NASA  under  a  RAND  Corporation 
contract.  Present  development  is 
being  sponsored  by  Project  RAND. 

Date  of  Release:  Not  yet  released 

Status :  Under  development 

Machine  Implementation:  ECSS  is  presently  on  an  IBM  360.  A 

SIMSCRIPT  II  compiler  is  required  in 
order  to  implement  ECSS.  Core  require¬ 
ments  vary  depending  on  the  specific 
simulation  being  conducted,  but  about 
100K  bytes  seem  to  be  the  norm. 

2.  Major  Features 

ECSS  is  an  extension  of  SIMSCRIPT  II  and  combines  the  full 
SIMSCRIPT  II  capability  with  more  specific  capabilities  for  model¬ 
ing  computer  systems*  ECSS  language  statements  are  written  in  a 
fairly  free  form,  translated  into  SIMSCRIPT  II  commands,  and  sub¬ 
sequently  compiled  by  SIMSCRIPT  II.  Statements  can  be  formed  by 
combining  ECSS  and  SIMSCRIPT  II  type  statements,  and  the  user  can 
augment  commands*  Flow-oriented  problems,  not  suitably  handled  by 
SIMSCRIPT  itself,  can  be  handled  by  ECSS  due  to  special  commands 
built  into  ECSS. 

A  binary  deck  is  produced  as  an  output  when  an  ECSS  simulation 
is  run.  This  deck  can  be  used  in  subsequent  runs  to  avoid  the  trans¬ 
lation  process. 

ECSS  appears  to  be  a  good  combination  between  a  proven  general 
purpose  simulation  language  (SIMSCRIPT  II)  and  an  easy  to  use 
flexible  command  structure  for  modeling  computer  systems.  Its 
present  drawbacks  include  a  weak  report  generation  (depends  on 
SIMSCRIPT  II)  and  weak  software  definition  capability  (again  requir¬ 
ing  SIMSCRIPT  II  coding).  There  is  presently  no  user  documentation 
available  and  experience  with  the  prototype  system  is  limited. 
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3.  Application 


Since  ECSS  is  still  in  development,  there  is  little  data  avail¬ 
able  on  application  experience •  Several  small  models  have  been 
written  and  tested  at  RAND,  but  full  field  testing  (due  early  in  1971) 
must  be  completed  before  ECSS  potential  in  the  application  area  can 
be  appraised. 
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PDL  -  Program  Description  Language 


1.  Background  Information 

Author:  G.  K.  Hutchinson 

Originating  Organization:  Texas  Technological  College, 

Lubbock,  Texas 


Date  of  Release:  1968 

Status:  Unknown 

Machine  Implementation:  Unknown 
2.  Major  Features 

The  PDL  language  was  designed  to  provide  a  capability  for 
describing  the  programs  to  be  processed  in  the  simulation  of  multi¬ 
processor  computer  systems.  A  program  is  defined  in  terms  of  the 
logical  relationships  between  its  constituent  routines  and  in  terms 
of  each  routine* s  resource  requirements.  The  routines  are  defined 
to  be  uniform  in  resource  requirements  and  without  parallelism. 

Routines  may  be  constrained  until  the  necessary  resources  are 
available  and  assigned  by  the  operating  system  and/or  until  required 
predecessor  routines  have  been  processed.  Routine  dependency  may  be 
expressed  as  a  logical  AND  or  OR. 

Parallelism  between  programs  is  simulated  by  the  simultaneous 
execution  of  routines  and  is  unlimited,  constrained  only  by  the 
availability  of  resources;  it  is  thus  possible  to  simulate  reentrant 
code. 


The  language  set  consists  of  38  commands  which  describe  the 
interdependency  of  the  program  routines  and  which  control  the 
logical  flow  of  the  program  and  the  progression  of  time. 

Hutchinson  expresses  the  opinion  that  as  multiprocessor  opera¬ 
ting  systems  become  more  comprehensive,  users  may  be  required  to 
detail  the  logical  relationships  and  resource  requirements  of  the 
various  routines  in  their  programs  and  that  command  languages  with 
features  similar  to  PDL  will  be  developed  for  this  purpose. 
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PLS  -  Product  Line  Simulator 


1.  Background  Information 

Author:  Computer  Programming  Laboratory 

Originating  Organization:  Hughes  Aircraft  Company 

Date  of  Release:  Proprietary 

Status:  Currently  available  through  service  contract 

Machine  Implementation:  IBM  360/50  with  256  K 

2.  Major  Features 

PLS  is  a  computer  systems  simulation  language  and  processor, 
somewhat  like  ECSS  and  CSS,  that  was  developed  by  Hughes  primarily 
for  use  in  evaluating  computer  system  designs.  Since  designs  cannot 
be  evaluated  independent  of  their  environment,  PLS  also  provides  for 
the  description  of  operating  systems  and  application  programs. 

The  descriptive  material  on  PLS  available  to  date  provides  only 
a  rather  cursory  look  at  the  system  elements  modeled  and  the  purposes 
toward  which  utilization  might  be  directed.  These  elements  and 
purposes  appear  roughly  comparable  to  CSS,  ECSS,  and  S3.  No  infor¬ 
mation  concerning  the  structure  and  format  of  the  language  was 
given  in  the  document  reviewed,  other  than  the  statement  that 
library  routines  are  incorporated  in  the  language. 


Reference 

Hughes  Aircraft  Company,  Ground  Systems  Group,  Simulation  Models  - 
A  Tool  for  the  Development  of  Real-Time  Computer  Systems,  August 
1970. 
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SEAL  -  Simulation  .Evaluation  and  Analysis  Language 


1.  Background  Information 

Author:  D.  M.  Braddock 

Originating  Organization:  International  Business  Machines  Corp. 
Date  of  Release:  Unknown 
Status:  Unknown 

Machine  Implementation:  Unknown 

2.  Major  Features 

SEAL,  an  event-oriented  language,  is  an  extension  of  SIMSCRIPT 
1.5  and  includes  PL/I-like  data  structures  and  improved  list  pro¬ 
cessing  features.  It  does,  however,  lack  the  capability  for 
automatic  sampling  from  probability  distribution  functions. 


References 

D.  M.  Braddock  and  C.  B.  Dowling,  "Simulation  Evaluation  and 
Analysis  Language,"  IBM  360  D15,  1.005. 

"Simulation  Evaluation  and  Analysis  Language  (SEAL) ,  System 
Reference  Manual,"  IBM  Corp.  ,  17  January  1968. 
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SIMCOM  -  The  Simulation  Compiler 


1.  Background  Information 

Author:  Thomas  G.  Sanborn 

Originating  Organization:  Space  Technology  Laboratory,  under 

purchase  order  from  Thompson  Ramo 
Wooldridge,  Inc.,  in  support  of  their 
contract  to  supply  technical  direc¬ 
tion  to  the  Automatic  Data  Process¬ 
ing  Facility,  U.  S.  Army  Electronic 
Proving  Ground. 

Date  of  Release:  1959  (approximate) 

Status:  Unknown 

Machine  Implementation:  IBM  709 

2.  Major  Features 

In  the  context  of  SIMCOM  a  computer  simulation  program  is  one 
which  will  allow  one  computer  to  assume  the  operational  characteris¬ 
tics  of  another  computer  which  is  unavailable  or  may  exist  only  in 
the  design  stage.  SIMCOM  was  developed  to  assist  in  the  preparation 
and  modification  of  computer  simulation  programs.  It  is  not  itself 
a  simulation  program,  but  a  compiler  which  accepts  input  statements 
written  in  a  specialized  simulation-oriented  source  language  and  gen¬ 
erates  instructions  in  the  machine  language  of  the  host  computer 
(i.e.,  SCAT  for  the  IBM  709).  SCAT  is  included  as  a  subset  of  the 
language. 

The  statement  is  the  fundamental  unit  of  the  SIMCOM  language; 
two  classes  exist: 

a.  definition  statements  which  define  the  components  of 
the  simulated  computer 

b.  procedural  statements  which  define  the  data  manipulation 
or  control  functions  which  are  associated  with  the 
execution  of  instructions  within  the  simulated  computer 

A  simulation  program  written  in  SIMCOM  consists  of  the  following 
components : 
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a.  Machine  definition  -  describes  the  static  computer  in 
terms  of  registers,  memory,  input,  output,  keys,  and 
indicators. 

b.  Instruction  interpretation  -  describes  the  computer 
in  operation.  This  section  is  written  in  terms  of 
procedural  statements  and  describes  the  accessing  of 
instructions  from  the  storage  of  the  simulated  com¬ 
puter  plus  a  description  of  the  effects  of  the 
execution  of  each  instruction. 

c.  Panel  operation  -  describes  the  effect  of  operator 
intervention.  This  section  includes  an  interrogation 
of  the  status  of  each  console  key  and  a  description 
of  computer  response  to  activation  of  the  key. 

The  output  from  SIMCOM  consists  of  a  translation  of  the  source 
program  into  SCAT.  This  includes,  in  addition  to  a  direct  expansion 
of  the  procedural  statements,  the  generation  of  an  input/output 
supervisor  and  a  storage  management  routine  which  allocates  the 
storage  of  the  simulated  computer  to  the  various  709  storage  media. 

There  are  language  statements  for  keeping  track  of  time  and  by 
specifying  the  execution  times  of  instructions,  it  is  possible  to 
assess  total  elapsed  time  in  the  computer. 


3.  Application 


Sanborn  has  expressed  the  opinion  that  SIMCOM  provides  the 
vehicle  for  describing  various  computers;  but  that  beyond  the  timing 
of  benchmark  programs,  it  has  no  mechanism  for  computer  evaluation. 


Reference 

Thomas  G.  Sanborn,  "SIMCOM  -  The  Simulation  Compiler,"  Proceedings 
of  the  Eastern  Joint  Computer  Conference,  1959,  pp.  139-142. 
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SLANG  -  ^Simulation  Language 


1.  Background  Information 

Author:  L.  A.  Kalinichenko 

Originating  Organization:  Ukranian  Academy  of  Sciences,  Insti¬ 
tute  of  Cybernetics,  Kiev,  U.S.S.R. 


Date  of  Release:  Unknown 

Status :  Unknown 

Machine  Implementation:  Unknown,  possibly  the  BESM  6 
2.  Major  Features 

SLANG,  a  simulation-oriented  experimental  programming  language, 
was  designed  to  be  used  for  the  simulation  of  computer  systems. 

Computer  systems  are  characterized  by  a  great  number  of  devices 
for  storage,  processing,  and  transfer  of  data;  operation  of  which  is 
overlapped.  At  the  initial  stage  of  system  design,  the  following 
basic  system  characteristics  must  be  defined: 

a.  system  components  and  associated  parameters 

b.  configuration  of  communications  paths  between  system 
components 

c.  number  of  control  levels  of  different  processes 

d.  priority  system  for  various  data  flows 

e.  specification  of  operational  algorithms  of  the 
system  control  elements 

Kalinichenko  feels  that  problem-oriented  languages  are  not 
suitable  for  the  simulation  of  computer  systems  and  that  special 
simulation  languages  are  necessary  and  should  provide  the  following 
capabilities : 

a.  ability  to  use  the  language  for  a  formalized  system 
description 
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b.  ability  to  model  the  generation  of  flows  of  non-uniform 
requests 

c.  ability  to  construct  and  process  list  structures;  this 
requirement  derives  from  the  modeling  of  scheduling 
algorithms 

d.  ability  to  generate  random  variables  from  specified 
distributions  and  to  provide  convenient  means  for 
gathering  statistics 

After  a  comparative  analysis  of  current  simulation  languages 
(GPSS  II,  GPSS  III,  SIMSCRIPT,  SOL,  SIMULA)  and  experimental  program¬ 
ming  of  processes  representative  of  computer  systems,  the  author  con¬ 
cluded  that  SOL  provided  the  most  capability.  It  has  natural  and 
brief  notation;  its  special  objects  are  similar  to  computer  system 
components;  and  implementation  is  facilitated  by  the  simplicity  of 
its  procedural  part.  It  was,  therefore,  chosen  as  the  basis  for  the 
experimental  language,  with  the  intention  of  correcting  some  of  its 
inherent  deficiencies. 

In  contrast  to  SOL,  SLANG  allows  for  interaction  among  pro¬ 
cesses  by  means  of  exchange  transactions  and  further  allows  one 
transaction  to  reference  the  local  variables  of  another.  List  pro¬ 
cessing  techniques,  similar  to  those  of  SIMULA,  have  been  incorporated 
to  improve  the  flexibility  of  control  of  transaction  movement  in  the 
system.  The  SOL  techniques  for  synchronization  of  concurrent  pro¬ 
cesses  were  expanded.  With  a  list  processing  capability,  SLANG  now 
has  the  capability  to  control  event  sequencing  by  two  alternative 
methods  and  to  compare  their  relative  effectiveness. 

3.  Application 

An  example  of  simulation  of  a  multi-terminal,  time-sharing 
computer  system  is  included  in  the  reference  to  illustrate  the 
language  features . 


Reference 

L.  A.  Kalinichenko,  "SLANG  -  Computer  Description  and  Simulation- 
Oriented  Experimental  Programming  Language, 11  in  J.  N.  Buxton,  ed. , 
Simulation  Programming  Languages ,  North  Holland,  Amsterdam,  1968, 

pp.  101-116. 
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COMPUTER  SYSTEMS  SIMULATION  PACKAGES 
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BOSS  -  Burroughs  Operational  Systems  ^Simulator 


1.  Background  Information 

Authors:  A.  J.  Meyerhoff 

P.  F.  Roth 
J.  P.  Troy 

Originating  Organization:  BOSS  was  originated  in  the  Burroughs 

Defense  Space  and  Special  Systems 
Group  of  the  Advanced  Development 
Organization  although  it  is  presently 
being  supported  by  the  Modeling  and 
Simulation  Group  of  the  DSSSG  Market¬ 
ing  Support  organization  at  Paoli, 
Pennsylvania. 

Date  of  Release:  1968 

Status:  Current 

Machine  Implementation:  BOSS  is  implemented  on  the  Burroughs 

B5500  system.  BOSS  (implemented  in 
ALGOL)  is  a  Burroughs  proprietary 
package  and  is  not  available  for 
implementation  on  other  than  Burroughs 
computers  at  the  present  time.  Specific 
information  on  peripheral  requirements, 
core  requirements,  etc.  for  the  B5500 
implementation  or  implementation  on 
other  Burroughs  computers  is  not 
available  at  this  time. 

2.  Major  Features 

BOSS  is  similar  in  many  respects  to  GPSS.  It  is  a  discrete- 
event,  block-diagram  oriented  system.  BOSS  maintains  a  unext-eventn 
file  which  is  triggered  by  the  changes  in  state  of  the  system  being 
modeled  as  opposed  to  triggering  on  fixed  increments  of  time. 

BOSS  considers  the  world  as  composed  of  processes,  tasks,  and 
units.  In  this  context  a  process  defines  the  priority  and  sequence 
of  tasks  to  be  performed  and  controls  the  generation  of  process  starts. 

A  task  is  any  discrete  operation  which  consumes  time  and  resources. 

The  unit  is  considered  as  a  resource  element  and  is  used  in  a  pool 
concept  by  the  various  tasks  to  carry  out  a  process. 
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BOSS  generates  several  reports  including  data  on  queue  statis¬ 
tics,  unit  utilization,  processor  job  mix  statistics,  memory  utiliza¬ 
tion,  etc.. 

The  block  symbology  used  for  defining  inputs  is  structured  in  a 
fairly  simple  way  and  appears  to  facilitate  the  definition  job  it¬ 
self,  but  it  may  lack  flexibility  if  used  in  widely  dispersed  appli¬ 
cation  areas. 

3.  Applications 

BOSS  is  designed  for  the  simulation  of  computer  systems,  although 
it  can  be  used  for  systems  with  similar  characteristics  in  the  sense 
that  BOSS  is  discrete-event  oriented. 


References 

A.  J.  Meyerhoff,  P.  F.  Roth,  and  J.  P.  Troy,  "BOSS,  Applications 
Manual,"  July  19,  1968,  Burroughs  Corporation,  Defense  Space  and 
Special  Systems  Group. 

P.  F.  Roth,  "The  BOSS  Simulator  -  An  Introduction,"  Proceedings 
of  the  Fourth  Conference  on  Applications  of  Simulation,  New  York  City, 
December  1970. 
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CASE  -  Computer  Aided  Systems  Evaluation 


1.  Background  Information 

Author:  Unknown 

Originating  Organization:  Computer  Learning  and  Systems  Corp. 

Date  of  Release:  1969 

Status:  Current  version  CASE  III 

Machine  Implementations: 

IBM  360/50 
GE  635 
CDC  6000 
1108  Univac 

2.  Major  Features 

CASE  is  a  statistical  simulator  capable  of  analyzing  batch 
processing,  multiprogramming,  multiprocessing,  time-sharing,  and 
real-time  computer  systems.  It  is  written  in  ASA  FORTRAN  with  some 
event  features  similar  to  SIMSCRIPT.  Like  SCERT,  CASE  consists  of 
a  collection  of  timing  algorithms  used  in  conjunction  with  a  library 
of  hardware  and  software  factors  to  simulate  a  computer  system  and 
evaluate  its  performance  in  processing  a  given  workload. 

Input  definitions  of  the  workload  and  system  configuration  are 
provided  via  coding  forms  and  considerable  flexibility  in  level  of 
detail  is  allowed.  The  workload  specification  is  in  machine 
independent  form  and  includes  such  items  as  general  system  type, 
file  definitions,  run  sequences,  and  for  each  constituent  run,  its 
identification,  language,  frequency,  I/O  files,  internal  processing 
activity,  and  output  reports.  The  processing  activity  is  charged 
against  files  and  may  be  specified  in  terms  of  higher  level  macros 
and  subroutines  or  by  explicitly  delineating  the  operations. 

Frequency  of  occurrence  may  be  expressed  exactly  or  as  a  probability. 

The  system  configuration  to  be  analyzed  is  specified  in  terms 
of  the  hardware  and  operating  system  software.  Information  is 
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provided  relative  to  the  operating  system,  CPU,  channels,  tapes, 
immediate  access  storage  devices,  and  peripherals.  Each  unit  is 
described  by  its  model  number,  quantity,  and  physical  connection. 

File  allocations,  file  blocking  factors,  and  device /channel 
assignments  either  may  be  specified  or  can  be  optimized  by  the 
simulator.  The  CASE  library  is  an  input  to  a  CASE  simulation  and 
provides  the  source  of  information  relative  to  the  technical 
characteristics  and  cost  of  the  hardware  and  software  system  packages 
marketed  by  the  major  computer  manufacturers.  These  data  are  used 
as  parameters  in  a  generalized  model  of  a  computer  hardware/sof t- 
ware  configuration. 

The  CASE  control  program  is  comprised  of  four  major  subsystems. 
Each  is  described  in  terms  of  its  major  function: 

a.  Independent  Processing  Analyzer  (IPA)  simulates  the 
system  in  batch  mode  operation.  For  each  constituent  run 
in  the  workload,  a  Run  Description  Report  is  prepared 
which  summarizes  data  relative  to  the  file  requirements, 
processing  activity,  and  output  reports.  This  report  is 

of  value  in  the  preparation  of  specifications.  Additionally, 
summary  statistics  for  system  component  utilization  are 
generated  over  all  the  runs  in  the  workload. 

b.  Concurrent  Processing  Analyzer  (CPA)  operates  on  inputs 
from  the  other  analyzers  in  conjunction  with  any  con¬ 
figuration  changes,  determines  an  optimum  run  schedule 
based  on  considerations  of  run  dependencies  and  priorities, 
and  simulates  the  workload  in  a  multi-programming  mode  of 
operation.  This  simulation  provides  reports  to  document 
the  run  schedule,  to  provide  a  time  history  and  activity 
analysis  of  the  component  jobs,  and  to  document  overall 
system  performance  and  requirements. 

c.  The  Real  Time  Analyzer  (RTA)  provides  the  algorithms  and 
logic  necessary  to  construct  a  model  of  a  computer  system 
operating  in  a  real-time  environment.  The  RTA  simulates 
generation  and  flow  of  information  through  the  system  and 
provides  reports  which  record  response  time,  maximum  queue 
lengths,  and  configuration  utilization. 

d.  Time  Sharing  Analyzer  (TSA)  is  a  specialized  package  which 
analyzes  complex  time  sharing  systems.  The  capability 
exists  to  perform  detailed  analysis  on  systems  employing 
such  advanced  techniques  as  virtual  memory,  partial  execu¬ 
tion,  and  page  swapping. 
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The  execution  of  CASE  is  an  iterative  process  in  which  the 
analyst  modifies  the  input  and  makes  the  configuration  and  design 
adjustments  necessary  to  achieve  an  optimal  system  design  for  pro¬ 
cessing  the  specified  workload.  Design  adjustments  take  the  form  of 
consolidating,  simplifying,  or  eliminating  certain  files  and  runs. 
Configuration  adjustments  are  of  greater'  magnitude  and  involve  the 
addition  or  deletion  of  channels,  controllers,  or  memory  or  the 
specification  of  a  different  set  of  mass  storage  units,  etc. 

These  decisions  are  made  on  the  basis  of  detailed  output 
reports  which  represent  a  distillation  of  the  statistics  gathered 
during  the  execution  of  the  simulation.  Reports  are  provided  at  the 
completion  of  each  simulation  iteration.  In  addition  to  the 
traditional  outputs  of  an  automatic  timing  routine,  CASE  supplies 
reports  which  aid  the  design  process  by  providing  the  theoretical 
limits  which  can  be  achieved  by  sub -optimizing  system  components. 
After  an  optimal  system  configuration  is  achieved,  reports  of  a 
higher  level  of  abstraction  are  prepared  for  management  which  docu¬ 
ment  the  final  solution. 

3.  Applications 

Reference  2  delineates  the  basic  features  of  CASE,  SCERT,  and 
SAM.  Bairstow  reports  the  user  impression  that  CASE,  being  of 
more  recent  origin,  is  better  designed  than  SCERT  to  model  third 
generation  features  such  as  multiprogramming,  real-time,  and  time¬ 
sharing  systems.  There  was  no  user  experience  with  multiprocessing 
systems.  However,  the  author  makes  the  point  that  CASE  is  able  to 
measure  hardware  contentions  in  a  single  system  and  may  be  able  to 
do  so  for  a  multiprocessor  configuration. 


References 

MA  Technical  Description  of  the  CASE  System,"  Software  Products 
Corporation. 

Jeffrey  N.  Bairstow,  "A  Review  of  Systems  Evaluation  Packages," 
Computer  Decisions,  June  1970,  p.  20. 
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System  Design  and  Optimization,"  Second  Conference  on  the  Applications 
of  Simulation,  New  York,  1968,  pp.  286-290. 
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COST  -  Computer  Optimized  System  Tradeoffs 


1.  Background  Information 
Author:  George  Pan 

Originating  Organization:  Interactive  Sciences  Corporation, 

now  operated  by  System  Architects 

Date  of  Release:  Not  released 

Status :  Proprietary 

Machine  Implementation:  GE-635 

PDP-10 


2.  Major  Features 

COST  is  neither  a  language  nor  a  model,  but  an  overall  method¬ 
ology  combining  simulation  with  theoretical  analysis  for  the  pur¬ 
pose  of  analyzing  computer  systems.  The  simulations  employed  util¬ 
ize  one  or  more  of  a  group  of  programs  along  with  a  library  of 
system  entities  and  their  attributes.  Its  originators  claim  result 
accuracies  of  +  10%  without  past  history  from  users  and  without  a 
benchmark  profile,  through  utilizing  the  "simplest  deterministic 
saturation  analysis  model."!  If  the  subject  for  analysis  is  a 
presently  functioning  system  and  actual  and  consistent  user  pro¬ 
files  are  available,  then  "one  of  the  generic  Monte  Carlo  models  ... 
used  for  a  particular ^COST  run  ...  can  (produce)  accuracies  ...  on 
the  order  of  "t  0.5%*"  The  major  strengths  of  this  approach,  and 
its  differences  from  other  simulators  such  as  SCERT,  lie  in  the 
optimization  of  file  design,  data  base  design,  and  network  design. 
Many  of  COST'S  applications  have  been  in  this  area. 

3.  Applications 

The  capability  summarized  by  the  acronym  COST  has  been  applied 
in  a  large  number  of  studies  done  for,  among  others,  the  Library  of 


^Interactive  Sciences  Corporation,  Memorandum  titled  "Computer  Sys¬ 
tems  -  Analysis  and  Simulation,"  p.  9. 

2Ibid. ,  p.  9. 
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Congress,  the  University  of  California,  Harvard  University,  Dart¬ 
mouth  College,  NASA,  Office  of  Education  of  H.E.W. ,  ONR,  a  number 
of  private  industrial  firms  including  Honeywell  EDP,  GE  Information 
Systems,  IBM,  and  Control  Data,  and  for  the  Decision  Sciences  labora¬ 
tory  of  ESD  as  well  as  MITRE  Washington. 


References 

"A  Brief  Introduction  to  Interactive  Sciences  Corporation,"  Inter¬ 
active  Sciences  Corporation,  Braintree,  Mass. 

"Computer  Systems  -  Analysis  and  Simulation,"  Interactive  Sciences 
Corporation,  Braintree,  Mass. 
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86 


DPSS  -  Data  Processing  Systems  ^Simulator 


1.  Background  Information 

Authors:  Michael  I.  Youchah 
Donald  D.  Rudie 
Edward  J.  Johnson 

Originating  Organization:  Systems  Development  Corporation 

Date  of  Release:  1964 

Status:  Expanded  DPSS  -  Model  C 

Machine  Implementation:  AN/FSQ  -  32  -  V 

IBM  7090/7094 


2.  Major  Features 

The  Data  Processing  System  Simulator  (DPSS)  is  a  general  pur¬ 
pose  computer  system  simulation  package  designed  to  aid  in  the  eval¬ 
uation  of  the  performance  and  response  characteristics  of  a  proposed 
computer  system.  The  design  being  tested  can  be  subjected  to  var¬ 
ious  workloads  and  data  processing  disciplines.  Constructed  by  the 
Systems  Development  Corporation  for  use  in  analyzing  the  operating 
performance  requirements  for  the  Strategic  Air  Command  Control  Sys¬ 
tem  (Project  465L) ,  the  DPSS  has  been  primarily  applied  in  the  area 
of  real-time  management  information  and  command /control  type  systems. 

The  DPSS  is  an  event-oriented  simulator,  written  in  JOVIAL, 
which  employs  higher  order  macros  combined  in  a  single  logical 
sequence  designed  so  as  to  permit  the  representation  of  a  wide  range 
of  system  configurations  and  processing  algorithms. 

The  DPSS  is  used  to  model  computer  systems  which  may  be  concep¬ 
tualized  as  consisting  of  input,  processing,  and  output  phases. 

The  inputs  consist  of  message  or  information  units  which  are  entered 
into  the  system  either  locally  or  via  remote  terminals.  These  units 
are  queued  and  processing  is  initiated  under  control  of  the  batch- 
ing,  priority,  and  interrupt  rules  in  effect.  The  processing  phase 
consists  of  retrieving  from  auxiliary  storage  the  appropriate  pro¬ 
grams  and  environment  and  executing  the  specified  sequences  of  in¬ 
structions.  During  the  terminal  phase,  the  necessary  data  is  aggre¬ 
gated,  formatted,  and  displayed  as  required. 
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Input  to  a  representative  DPSS  simulation  would  include  the 
specification  of  message  types,  traffic  rates,  batching  criteria, 
task  processing  times  to  load  and  operate  (expressed  as  probability 
distributions  with  associated  parameters),  message-task  and  message- 
display  relationships,  task  sequences,  etc.  Output  consists  of 
statistics  related  to  the  transmission  history  of  each  message  in 
the  system  and  to  the  state  of  the  system  during  each  replication 
of  the  cycle. 

An  expanded  DPSS  (Model  C)  has  been  developed  which  allows  for 
the  simulation  of  more  sophisticated  computer  systems.  Future  devel¬ 
opments  are  expected  to  be  in  the  area  of  multi-  and  parallel  pro¬ 
cessing. 

3,  Applications 

The  DPSS  was  used  successfully  in  the  design  and  development  of 
465L  SACCS.  Details  of  this  application  are  included  in  the  refer¬ 
ence.  Additionally,  it  proved  useful  in  evaluating  original  con¬ 
cepts  relating  to  the  Space  Surveillance  Project  and  the  New  York 
State  Identification  and  Intelligence  System. 

The  authors  of  DPSS  state  that  "it  is  a  powerful  tool  in  per¬ 
forming  system  feasibility  studies,  simulating  the  operation  and 
performance  of  computer-based  data  processing  systems,  and  in  eval¬ 
uating  equipment  and  data  processing  discipline  combinations  as  a 
function  of  system  operational  requirements. " 


Reference 

M.  I.  Youchah,  D.  D.  Rudie,  and  E.  J.  Johnson,  nThe  Data  Processing 
System  Simulator  (DPSS)/1  Proceedings  AFIPS  1964  Fall  Joint  Computer 
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S3  -  The  System  and  jSoftware  ^Simulator 

1.  Background  Information 
Author:  Leo  J.  Cohen 

Originating  Organization:  CEIR,  Inc*,  Under  Contract  from  the 

United  States  Army  Computer  System 
Evaluation  Command 

Date  of  Release:  1968 

Status:  Only  basic  documentation  available. 

Machine  Implementation:  Written  in  FORTRAN  IV;  successfully 

executed  on  IBM  360/50/65/75,  and 
Univac  1108 


2.  Major  Features 

S3  is  a  discrete  event-oriented  simulator  designed  specifically 
for  modelling  computer  systems.  Its  operation  is  dynamic  (i.e.,  a 
user  defined  system  description  results  in  a  representative  simula¬ 
tion  such  that  the  actual  time  to  run  the  simulation  depends  upon 
the  length  of  the  time  period  being  simulated).  It  utilizes  five 
types  of  information:  a  hardware  characteristics  data  base,  a 
description  of  the  operating  system,  configuration  data  for  hardware 
and  software,  user  program  descriptions,  and  file  organization 
information  for  application  programs.  S3  produces  sets  of  statistics 
concerning  utilization  of  hardware  resources,  effectiveness  of  the 
operating  system,  and  performance  measures  for  application  programs. 

The  five  types  of  input  data  are  described  in  a  defined  speci¬ 
fication  language,  and  each  type  is  substantially  independent  of  the 
others.  For  example,  the  descriptions  of  particular  units  of  hard¬ 
ware  are  independent  of  the  way  in  which  the  hardware  units  are 
interconnected.  The  level  of  detail  involved  can  be  appreciated  by 
viewing  the  table  which  follows. 

Processing  by  S3  is  done  in  four  phases.  In  the  first  of  these, 
the  hardware /software  specifications  in  the  defined  programming  and 
job  control  "languages"  are  "assembled",  i.e.,  they  are  reduced  to 
compact  description  through  a  translation  process.  Next,  this 
assembled  code  is  used  to  generate  a  model  of  the  system  to  be  sim¬ 
ulated.  In  the  third  phase,  this  model  is  used  to  produce  a  record 
of  the  simulated  performance  of  the  system  over  a  period  of  time. 
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Table  II 


Sample  S3  Specifications 


ELEMENT 

DESCRIPTORS 

1.  Hardware  Performance 


Printer 

Characters/Line,  Lines/Second, 
Start/Stop  Time,  Skip  Time 

Tape  Drive 

Data  Storage  Unit  (bit,  byte,  word), 
Inter-Record  Gap,  Start/Stop 

Time,  Rewind  Time,  Successive 

I/O  Reference  Delays 

Data  Controllers 

Data  Unit  Transmitted  (bit,  byte, 
word) ,  Selector/Multiplexor, 
Simplex/Half /Full  Duplex 

CPU 

Add/Multiply/Divide  Time  for 

Decimal /Fixed/Floating  Cycle 

Rate,  Average  Instruction  Time 

Core  Memory 

Access  Rate,  Data  Storage  Units 
(bit,  byte,  word),  Size 

2.  Hardware  Configuration 

Controllers/Channels  to  which  each 
unit  is  connected ;  allowable 

CPU -memory  connections;  number 
and  type  of  processors  and  net¬ 
works  of  computers 

3.  Operating  System 

Programming  Language11  to  express 

0/S  flowchart  logic;  core  allo¬ 
cation  and  reassignment  tech¬ 
niques;  queue  manipulation 
doctrines;  control  methodology; 
interrupts  internal  and  external 
to  particular  CRJs;  overlay  and/ 
or  multiprogram  structure 

4.  Application  Programs 

Program  Language"  for  representa¬ 
tion  of  program  flow,  including 
program/subprogram  structure, 

I/O  commands,  parallel  processing 
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Table  II  (Concluded) 


ELEMENT 

5,  Application  File 


DESCRIPTORS 


Structure  "Job  Control  Language"  describes 
application  program  file  struc¬ 
ture  and  distribution  among 
peripherals,  amount  of  storage 
required  for  instruct ions /con¬ 
stants/data,  frequency  of  pro¬ 
gram  operation  using  fixed/ 
stochastic  interval,  variability 
in  storage  requirements  during 
processing,  calls  to  external 
programs 
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Finally,  this  performance  data  is  reduced  through  statistical  analysis 
to  performance  reports. 

These  performance  reports  are  composed  of  statistical  data  out¬ 
lining  the  operation  of  each  defined  facility  and  each  program  in 
the  system.  Included  are  data  concerning  utilization  and  overhead 
time  for  devices,  controllers,  channels,  CRJs  and  memory,  a  detailed 
summary  of  interrupts,  memory  repacking  (if  utilized),  queue  history, 
and  a  breakout  of  area  memory  utilization.  Minimum,  maximum  and 
average  turn-around  and  execution  times  are  reported  for  application 
programs  along  with  breakouts  of  time  allocated  for  CRJ,  I/O,  and 
queue  delay.  The  minimum,  maximum  and  average  number  of  file  refer¬ 
ences  is  reported  for  each  program. 

3.  Applications 

S3  has  been  utilized  in  designing  multiprogramming  control  of  a 
computer  used  for  process  control  with  off-line  program  background, 
for  design  of  real-time  airborne  hardware/operating  systems  for 
multiprocessor  configurations,  and  for  performance  evaluation  of 
systems  utilizing  the  Litton  3050M,  the  IBM  4Pi,  and  the  Burroughs 
D84T  computers. 


References 
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SAM  -  Systems  Analysis  Machine 


1.  Background  Information 

Author:  Leo  J.  Cohen 

Originating  Organization:  Applied  Data  Research  Inc. 

Date  of  Release:  1970 

Status:  Current 

Machine  Implementation:  IBM  360/50 

2.  Major  Features 

SAM,  System  Analysis  Machine,  is  a  computer  program  written  in 
FORTRAN  designed  for  the  discrete-step  simulation  of  the  operations 
of  digital  computer  systems.  The  facilities  allow  for  the  modeling 
of  the  hardware,  operating  system,  utility  programs,  and  applica¬ 
tions  programs  which  comprise  a  computer  system. 

Unlike  SCERT  and  CASE  in  which  system  data  is  specified  via 
definition  forms,  SAM  provides  a  dynamic  programming  language  as 
the  means  for  describing  computer  hardware/ software  characteristics. 

A  complete  SAM  model  is  comprised  of  the  following  basic 
elements: 

a.  The  Hardware  Module  consists  of  SAM  declarators  which 
describe  the  operational  characteristics  and  interconnections 
of  the  hardware  components  (example:  I/O  devices,  channels, 
CPU’s,  controllers,  etc.). 

b.  The  Program  Module  describes  the  component  software  of  the 
system.  The  declarators  provide  information  relative  to 
size,  language,  storage  requirements,  and  I/O  files. 
Additionally,  the  logic  of  each  program  as  described  by  flow 
charts  is  encoded  in  SAM  statements. 

c.  The  File  Module  describes  the  characteristics  of  the  files 
in  terms  of  direction  (input  or  output),  organization,  and 
format. 
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d.  The  Media  Module  describes  the  peripheral  storage  devices 
and  delineates  organization,  physical  properties,  and  file 
assignments. 

e.  The  System  Module  correlates  the  Hardware,  Program,  File, 
and  Media  Modules  and  incorporates  any  user  defined  FORTRAN 
subroutines. 

f .  The  Creation  Module  provides  data  relative  to  the  charac¬ 
teristics  of  the  jobs  and  the  rate  at  which  they  will  be 
generated  and  entered  into  the  simulation. 

The  SAM  System  consists  of  five  components;,  the  functions  of 
each  will  be  briefly  described. 

a.  The  Model  Library  consists  of  pre-defined  models  of  the 
hardware,  operating  systems,  and  utility  packages  of  the 
major  computer  manufacturers.  User  defined  models  may  be 
coded  in  the  SAM  language  and  entered  into  the  library. 
During  a  simulation,  macro  calls  will  extract  the  approp¬ 
riate  models  from  the  library. 

b.  The  SAM  Translator  is  comparable  to  a  compiler  in  that 
it  converts  "source  models"  written  in  the  SAM  language 
into  "object  models"  in  the  lower  level  code  required 
by  the  Model  Generator. 

c.  The  Model  Generator  performs  the  functions  of  a  linkage 
editor.  Operating  on  the  output  from  the  Translator,  the 
Generator  produces  a  complete  model  from  the  component 
modules  (i.e.,  hardware,  program,  file,  media  system,  and 
creation) . 

d.  The  model  produced  by  the  Generator  is  executed  by  the 
Interpreter.  Data  relative  to  system  performance,  device 
utilization,  and  program  efficiency  are  collected  and  for¬ 
matted  for  input  to  the  Data  Analyzer  and  Reporter. 

e.  The  Data  Analyzer  and  Reporter  generates  the  statistical 
results  of  the  simulation.  At  the  option  of  the  analyst, 
a  wide  range  of  output  reports  describing  system  perfor¬ 
mance  is  available. 

3.  Applications 

SAM  addresses  itself  to  a  wide  spectrum  of  problems.  The 
referenced  manual  states  that  the  Systems  Analysis  Machine  is  capable 
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r.f  modeling  real-time,  time-sharing,  multiprocessor,  and  multi¬ 
computer  systems. 

To  illustrate  the  features  of  the  language,  an  example  of  a 
tele-processing  system  is  included. 


References 
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Computer  Design,  July  1970. 

"Systems  Analysis  Machine  -  Introductory  Guide,"  Applied  Data 
Research,  Inc. 
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SCERT  -  Systems  and  Computers  Evaluation  and  Review  Technique 
COMET  -  Computer  Operated  Machine  Evaluation  Technique 


1.  Background  Information 

Author:  Fred  C.  Ihrer 

Originating  Organization:  COMRESS,  Inc.,  Rockville,  Maryland 

Date  of  Release:  1962 

Status:  Current  version  SCERT  50 

Machine  Implementations:  IBM  360  series 

UNI VAC  1108 
Spectra  70  series 

2.  Major  Features 

SCERT  was  the  first  of  the  commercially  available  systems  evalua¬ 
tion  packages.  The  Air  Force  presently  owns  a  version  of  the  simulator 
under  the  acronym  COMET.  Since  COMET  represents  a  basic  simulation 
capability  within  the  Air  Force,  it  is  treated  in  somewhat  greater  depth 
than  the  other  packages  described  in  this  section. 

It  provides  the  capability  to  simulate  the  performance  of  a  user's 
processing  requirements  against  cost/performance  models  of  selected 
computer  hardware/ software  systems.  Written  in  assembly  language,  it  is 
essentially  an  algorithmic  simulator  incorporating  discrete  event  simu¬ 
lation  techniques  only  in  the  case  of  randomly  occurring  processing. 

SCERT  is  an  evolutionary  tool  and  has  been  modified  as  necessary 
to  keep  pace  with  and  accurately  reflect  advances  in  computer  technology. 
Originally  designed  to  simulate  batch  systems,  it  has  been  updated  to 
the  current  version,  SCERT  50,  which  is  capable  of  simulating  multipro¬ 
gramming,  multiprocessing  and  real-time  systems. 

SCERT  may  be  run  in  either  of  two  modes,  review  or  evaluation. 

The  evaluation  mode  includes  optimizing  features  such  as  blocking  of 
records,  assignment  of  peripheral  units  to  I/O  channels,  allocation  of 
memory,  and  scheduling  of  a  multiprogramming  workload.  In  the  review 
mode  these  parameters  are  specified  by  the  user,  and  the  simulator 
merely  determines  the  execution  timings  and  hardware  utilization.  The 
review  mode  of  operation  is  useful  in  validating  a  base  case  configura¬ 
tion  by  comparing  the  simulation  results  with  known  throughput  data. 
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The  user  may  then  change  values  of  parameters  and  run  in  the  evaluation 
mode,  and  SCERT  will  apply  the  appropriate  optimizing  algorithms.  These, 
however,  are  limited  to  those  previously  noted,  and  it  remains  the 
responsibility  of  the  systems  analyst  to  study  the  output  reports  and 
initiate  changes  in  equipment  configuration  and  program  design  which 
have  the  potential  of  enhancing  system  performance. 

The  SCERT  package  consists  of  four  major  components: 

1.  Definition  languages 

2.  Factor  library 

3.  Simulation  programs 

U  Output  reports 

The  definition  languages  define  the  applications  systems  and  the 
hardware/software  configurations  to  be  analyzed.  Processing  require¬ 
ments  are  delineated  for  each  computer  program  or  random  event  which 
comprise  the  projected  workload.  Each  application  program  is  defined 
in  terms  of  priority,  pre-requisites,  frequency,  I/O  files,  and  inter¬ 
nal  processing  requirements.  These  processing  requirements .may  be 
specified  in  terms  of  basic  computer  activity  (add,  compare,  move,  etc.) 
or  at  a  higher  functional  level  (extract,  validate,  sort,  etc.)  depend¬ 
ing  upon  the  stage  of  program  design.  Random  processes  arc  modeled  as 
a  series  of  sequential  sub-processes  where  each  sub-process  is  defined 
as  one  computer  run.  Additionally,  each  file  involved  in  the  system 
processing  is  defined  in  terms  of  number  of  records,  characters  per 
record,  number  of  alpha  and  numeric  fields,  media,  etc. 

The  hardware/software  configurations  are  specified  by  component 
model  number  and  quantity.  The  hardware  must  be  specified  in  exact 
detail  including  all  adaptors,  channels,  and  control  units.  The  user 
may  specify  the  allocation  of  peripheral  devices  to  channels  and  the 
terminal  interfaces  in  communications  networks.  The  software  packages 
which  are  to  be  used  in  conjunction  with  the  hardware  are  also  specified 
on  input  definition  forms.  Included  are  a  specification  of  the  operating 
system,  compilers,  sort  and  IOCS  packages,  etc. 

Finally,  the  system  environment  definition  includes  such  items  as 
programmer  experience  profile,  salaries,  corporate  cost  of  money,  and 
svetem  life  expectancy. 

The  SCERT  tactor  library  is  a  technical  data  base  which  contains 
factors  concerning  the  performance  of  commercially  available  computer 
hardware  and  software.  The  hardware  factors  include  cost,  environment, 
specification,  and  performance  data  relative  to  central  processing 
units,  peripheral  components,  control  units,  and  special  features.  The 
software  factors  include  capability,  capacity,  and  overhead  data  rela¬ 
tive  to  generalized  software  packages  such  as  compilers,  operating  sys¬ 
tems,  IOCS,  and  sort  routines. 
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Conceptually,  SCERT  simulation  programs  may  be  viewed  as  having 
five  functional  phases.  Phase  1  accepts  as  input  the  systems,  file  and 
environment  definitions,  and  builds  a  hardware- independent,  mathematical 
model  of  the  processing  requirements  of  each  computer  run  and  real-time 
event  in  the  system.  These  models  are  verified  and  output  diagnostics 
generated  as  necessary. 

Phase  2  accepts  as  input  the  definitions  of  the  hardware  components 
and  software  packages  which  comprise  the  configuration  to  be  analyzed. 
Appropriate  factors  are  retrieved  from  the  library  and  mathematical 
models  are  built  which  represent  the  hardware  configuration,  the  soft¬ 
ware  packages,  and  the  effect  of  the  integration  of  hardware  and  soft¬ 
ware.  The  Phase  1  processing  models  are  validated  for  compatibility 
with  the  Phase  2  models. 

Phase  3  of  SCERT  consists  of  the  execution  of  the  pre-simulation 
algorithms.  The  processing  requirements  developed  in  Phase  1  are 
adjusted  to  conform  to  the  capability  of  the  hardware/software  complex 
specified  in  Phase  2.  For  each  program  or  random  event  in  the  applica¬ 
tions  workload  the  following  data  are  computed: 

1.  Internal  processing  time 

2.  Memory  requirements 

3.  Assignment  of  files  to  peripheral  devices  and  channels 

4.  Structuring  of  the  files  to  the  hardware 

5.  Throughput  timing  and  memory  requirements  for  all  I/O  functions 

6.  Timing  of  generalized  software  packages 

7.  Pre-  and  post-run  timing 

The  actual  simulation  is  executed  in  Phase  4  via  three  distinct  stages. 
Stage  1  is  considered  the  throughput  simulation.  SCERT  explodes  each 
program  run  and  random  event  into  its  maximum  number  of  iterations, 
simulates  the  flow  of  each  through  the  specific,  computer  configuration, 
and  derives  net  throughput  timing.  These  data  are  based  on  the  com¬ 
posite  representation  of  I/O  and  internal  timing  generated  by  the  pre¬ 
simulation  algorithms,  and  all  available  simultaneity  is  accounted  for. 
The  resultant  timing  reflects  system  operation  in  a  sequential  batch 
mode  (i.e.,  a  non-mul tiprogrammed  environment). 

Stage  2  consists  of  the  event-oriented  simulation  and  is  executed 
only  if  the  defined  processing  includes  real-time  events.  Probabalistic 
models  of  events  occurring  during  the  total  cime  frame  are  developed;  and 
the  flow  of  these  models  through  the  computer  system  is  analyzed  to 
determine  the  load  imposed  on  potential  queue  points  (CPU,  mass  storage, 
peripherals),  the  average  and  maximum  delay  times  for  messages,  and  the 
effect  of  real-time  interrupts  on  background  batch  jobs. 
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Stage  3  consists  of  the  time-oriented  simulation;  it  is  entered 
whenever  the  system  specifications  include  a  multiprogramming  or  multi¬ 
processing  capability.  Employing  critical  path  techniques,  SCERT 
determines  the  degree  of  concurrency  available  and  derives  a  schedule 
of  tasks  based  on  considerations  of  priorities,  processing  requirements, 
and  pre-requisites. 

In  summary,  Stages  1  and  2  determine  the  net  elapsed  time  (vertical 
utilization)  and  capacity  requirements  (horizontal  utilization)  for  each 
scheduled  run  and  real-time  event.  Stage  3  generates  time  stream  records 
of  processing  requests  which  are  sorted  into  sequence  by  priority  within 
a  time  zone.  These  time  stream  records  are  passed  against  a  model  rep¬ 
resenting  the  total  capacity  of  the  computer  system  in  terms  of  memory 
available,  total  peripherals,  internal  processing  capacity,  channels 
available,  etc.  Each  record  is  examined,  requirements  are  matched  to 
available  capacity,  and  a  schedule  of  tasks  that  should  be  run  in  paral¬ 
lel  to  achieve  maximum  throughput  is  determined. 

The  last  functional  component  of  SCERT  consists  of  the  output 
report  generator.  A  full  complement  of  fourteen  reports  of  varying 
levels  of  detail  is  available  for  management  analysis.  Each  of  these 
may  be  selectively  requested  as  dictated  by  the  objectives  of  the  sim¬ 
ulation.  In  summary,  the  output  reports  are  as  follows: 

•System  Identification  -  for  each  program  run  and  real-time  event 

this  report  outlines  the  input  file  data,  internal  functional 
activities,  and  output  file  data. 

•  Configuration  Identification  and  Cost 

Computer  Complement  Report  -  identifies  the  configuration 
being  simulated  and  includes  certain  basic  cost  and 
environment  data. 

Cost  Summary  Report  -  the  lease,  purchase  and  maintenance 

costs  of  the  hardware  are  presented,  based  on  expected 
utilization. 

•  Sequential  Processing  Projections 

Central  Processor  Utilization  -  projects  for  each  run  the 

processing  time,  set-up  time,  and  memory  requirements. 
Additionally,  a  summary  report  is  generated  which  pro¬ 
rates  these  projections  into  daily,  weekly  and  monthly 
average  utilization. 

Computer  Capabilities  Report  -  tabulates  for  each  run  the 
hardware  devices  utilization. 
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Detail  Systems  Analysis  Report  -  a  three  part  report  produced 
for  each  scheduled  run  or  real-time  event  simulated. 

Part  1  -  analyzes  the  I/O  requirements  of  the  run  in 
terms  of  device  assignment,  file  blocking,  buffer  space, 
throughput  timing,  etc. 

Part  2  -  derives  the  internal  processing  time,  program 
steps,  and  memory  attributable  to  arithmetic  operations, 
decision  and  control,  data  handling,  and  I/O  control. 

Part  3  -  analyzes  pre-  and  post-run  overhead  functions. 

•  Random  Real-Time  Projections 

Event  Processing  Time  -  analyzes  each  real-time  event  in  terms 
of  its  unique  input,  output,  and  processor  time  indepen¬ 
dent  of  any  possible  queueing  delays. 

Hardware  Utilization  -  analyzes  all  potential  queue  points  in 
terms  of  utilization  and  derives  expected  and  worst  case 
queue  lengths. 

System  Response  Data  -  the  expected  response  of  each  event 
through  the  central  computer  complex  and  through  the 
communications  network  is  presented  for  the  99th,  95th 
and  50th  percentile  probability  levels. 

Memory  Requirements  -  tabulates  for  each  random  event  the 
memory  requirements  for  program  areas  and  data  areas. 

Also  presented  are  the  expected  and  worst  case  background 
memory  requirements. 

•  Multiprogramming/Multiprocessing  Projections 

Detailed  Multiprogramming  Schedule  -  provides  a  snapshot  of 
the  computer  system  at  every  point  in  simulated  time 
when  a  program  starts,  terminates  or  changes  state. 

Multiprogramming  Throughput  Summary  -  tabulates  the  complete 
time  history  for  each  scheduled  run  and  provides  data 
for  throughput  analysis. 

Multiprogramming  Utilization  Summary  -  presents  for  each  time 
zone  a  measure  of  system  utilization  in  terms  of  memory 
and  processor  capacity. 

•  Implementation  Projections 

Programming  Requirements  Report  -  breaks  down  each  program  run 
into  the  number  of  instructions  to  be  programmed  by  the 
user  and  supplied  by  utility  routines.  Additionally  a 
projection  is  made  of  the  programming  effort  in  man-months. 
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Application  Summary  Report  -  presents  a  summary  of  the  central 
processor  utilization  and  programming  effort  for  each 
unique  application  area  in  the  workload. 
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SECTION  IV 


BIBLIOGRAPHY 


The  bibliography  has  been  automated  via  the  KWIC  INDEXING  sys¬ 
tem  which  reads  reference  data  and  permutes  the  titles  on  a  complete 
or  selective  word  basis.  It  is  possible  to  annotate  the  titles  by 
keyword  descriptors ,  and  permutation  on  the  annotators  is  an 
additional  option.  Where  appropriate  the  references  have  been  so 
annoted  to  indicate  the  subject  language(s).  Preliminary  documenta¬ 
tion  has  been  collected  relevant  to  computer  systems  simulation; 
these  references  have  been  annoted  by  language/computer  system.  The 
entire  bibliography,  organized  by  author,  is  presented  as  Appendix 
A;  the  bibliography  indexed  on  the  languages  delineated  in  Section 
III  is  presented  as  Appendix  B. 

Several  of  the  references  are  of  an  expository  nature  and  deal 
with  the  basic  similarities  and  differences  that  exist  between 
simulation  languages.  Table  II  identifies  these  reference  sources 
and  delineates  the  languages  so  compared. 


10S/360  QUIC  (KWIC  INDEXING),  IBM  Corporation,  Contributed  Program 
Library,  360D-06. 7.022. 
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Table  III 


Comparison  of  Simulation  Languages 


LANGUAGE 

BIBLIOGRAPHY  REFERENCE 

D0010 

KOI 30  TOO 10 

TOO  30 

TOO  3  3 

CLP 

X 

CSL 

X 

X  X 

X 

X 

DYNAMO 

X 

ESP 

X 

GASP 

X 

GPSS 

X 

X  X 

X 

GSP 

X 

X 

HSL 

X 

MONTECODE 

X 

X 

RSP 

X 

SIMON 

X 

SIMPAC 

X 

X 

SIMSCRIPT 

X 

X  X 

X 

X 

SIMULA 

X 

X 

SOL 

X 

X 

D0010  -  0.  J.  Dahl,  "Discrete  Event  Simulation  Languages" 

K0130  -  H.  S.  Krasnow,  R.  A.  Merikallio,  "The  Past,  Present  and 
Future  of  General  Simulation  Languages" 

T0010  -  D.  Tiechroew,  J.  F.  Lubin,  "Computer  Simulation  -  Discussion 
of  the  Techniques  and  Comparison  of  Languages" 

T0030  -  K.  D.  Tocher,  "Review  of  Simulation  Languages" 

T0033  -  K.  D.  Tocher,  A.  P.  Amiry,  "New  Development  in  Simulation" 

Complete  references  may  be  found  in  the  computerized  bibliography 
listing. 
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APPENDIX  A 


A0005 


A001  0 


A0020 


A0030 


BU003 


BOOIO 


R  0030 


B  0040 


R0050 


BIBLIOGRAPHY  ON  SIMULATION 


ACM/A  I  IE/ IEEF/SHARE/SCI/TIMS  (SPONSOR) 

FOURTH  CONFFRENCE  ON  APPLICATIONS  OF  SIMULATION 
Nc W  Yi’RK,  NEW  YORK  (DEC.L970) 

APPLICATIONS 


ANOEKSON,  H  A 

SIMULATION  OF  THE  TIME-VARYING  LOAD  ON  FUTURE  REMOTE-ACCESS 
IMMEDIATE-RESPONSE  COMPUTER  SYSTEMS 


APPLIED  DATA  RESEARCH,  INC. 

SYSTEM  ANALYSIS  MACHINE 

APPLIED  DATA  RESFARCH,  INC.  (APRIL  1970) 
SAM 


ARMSTRONG,  J  ULFFRS,  H 

MILLER,  D  J  PAGE,  H  C 

SOLPASS,  A  SIMULATION  ORIENTED  LANGUAGE  PROGRAMMING  AND 
SIMULATION  SYSTFM 

PR  DC.  THIRD  CONF.  PN  APPLICATIONS  OF  SIMULATION,  LOS  ANGELES 
,  1969,  P. 76-27  (ACM/A IIE/IFEE/SHARE/SCI /TIMS) 

SOLPASS 


BAIRSTOW,  J  N 

A  REVIFW  OF  SYSTEMS  EVALUATION  PACKAGES 
COMPUTER  DECISIONS  (JUNE  1970),  P.20 
CASE  SAM  SCERT 


RLUNDEN,  G  P  KRASNOW,  H  S 

THE  PROCESS  CONCEPT  AS  A  BASIS  FOR  SIMULATION  MOOELING 
SIMULATION  (AUG. 1967),  P.89-93 


BRENNAN,  R  D  LINFBARGER,  R  N 

A  SURVEY  OF  DIGITAL  SIMULATION 
SIMULATION  (DEC. 1964),  P.22-36 
CONTINUOUS 


BUXTON,  J  N 

SIMULATION  PROGRAMMING  LANGUAGES 

PROC.  OF  I  FI P  WORKING  CONF.  ON  SIMULATION  PROGRAMMING 
LANGUAGES,  NORT H-HOLL AND  PUBLISHING  CO. -AMSTE ROAM  (1968) 


BUXTON,  J  N 

WRITING  SIMULATIONS  IN  CSL 

COMPUTER  JOURNAL  (AUG. 1966),  P.137-143 

CSL 
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80060  KUXTQN,  J  N  LASKI,  J  G 

CONTROL  AND  SIMULATION  LANGUAGE 

COMPUTFR  JOURNAL  5,3  (OCT. 1962),  P.194-200 

CSL 


COO’O  CALINGAPRT,  P 

SYSTEM  PERFORMANCE  EVALUATION:  SURVEY  ANU  APPRAISAL 
COMMUNICATIONS  OF  THE  ACM  (JAN. 1967),  VOL. 10,  NO. 1 ,  P.12-18 
APPLICATIONS 


C0O?0  CANNING,  R  G 

DATA  PROCESSING  PLANNING  VIA  SIMULATION 
EDP  ANALYZER  (APRIL, 1968)  VOL. 6,  NO. 4 


C0025  CHFNG,  P  S 

TRACE-DPIVFN  SYSTEM  MODELING 
I RM  SYST  J  8,4  (1969),  P.280-289 


COO  30  CLANCY,  J  J  FINFREP.G,  M  S 

DIGITAL  SIMULATION  LANGUAGES:  A  CRITIQUE  ANO  A  GUIDE 

PROC.  FJCC  (1965),  P.23-36 

CONTINUOUS 


COO 3?  CLARK,  S  »  ROUKE,  T  A 

A  SIMULATION  STUDY  OF  COST  OF  DELAYS  IN  COMPUTER  SYSTEMS 
PROC.  FOURTH  CONF.  ON  APPLICATIONS  OF  SIMULATION  ACM/AIIE 
IFEF/SHARE/SCI/T IMS  NEW  YORK, NEW  YORK  (DEC. 1970),  P.195-200 
AP PL IC AT  IONS 


C0040  CLFMENTSON,  A  T 

CXTENDED  CONTROL  AND  SIMULATION  LANGUAGE 
COMPUTER  JOURNAL  9.3  (NOV. 1966),  P.215-220 
ECSL 


C0050  COHEN ,  L  J 

SYSTEM  AND  SOFTWARE  SIMULATOR 

C-E-I-R,  INC.  WASHINGTON,  DC  (DEC. 1968),  AO  679  269,  VOL. 1 


CO 060  COHEN,  L  J 

S3,  THP  SYSTEM  AND  SOFTWARE  SIMULATOR 

DIGFST  OF  THE  SECOND  CONFERENCE  ON  APPLICATIONS  OF 

SIMULATION  (DEC. 1968),  P.282-285 

S3 


C 0070  COMRESS  -  ROCKVILLE,  MARYLAND 

A  TECHNICAL  DESCRIPTION  OF  SCERT 
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CUORO 


00010 


00020 


00030 


00040 


00050 


E0010 


F0003 


CONWAY »  R  W  DELFAUSSE.  J  J 

MAXWELL,  W  L  WALKER,  W  E 

CLP  -  THE  mPNFLL  LIST  PROCESSOR 

CO**M  IF  T Hr  ACM  (APRIL  1965),  VOL. 8,  NO. 4,  P.215-216 
CLP 


CAHL,  0  J 

01  SCR  F  TF  EVENT  SIMULATION  LANGUAGES 
LCCTURES  DELIVERED  AT  THE  NATO  SUMMER  SCHOOL, 
VILLARD-DE-LANS  (SEPT. 1966) 

CSL  G°SS  SIMSCRIPT  SIMULA  SOL 


OAHL,  0  J  NYGAARD,  K 

SIMULA  -  AN  ALGOL-BASED  SIMULATION  LANGUAGE 
COMMUNICATIONS  OF  THE  ACM  (SFPT.1966),  VOL. 9,  NO. 9, 
P. ‘'71-478 
SI MULA 


OAHL,  0  J  MYHPHAUG,  B 

NYGAARD,  K 

SOME  FEATURES  OF  THr  SIMULA  67  LANGUAGE 
01 GF ST  OF  THF  SECOND  CONFERENCE  ON  APPLICATIONS  OF 
SIMULATION  ( OF C • 1 9 68 ) ,  P.29-31 
SI MULA 


DONOVAN,  J  J  ALSOP,  J  W 

J  CNP  S  »  M  M 

A  GRAPHICAL  FACILITY  FOR  AN  INTERACTIVE  SIMULATION  SYSTEM 

PROC.  OF  IF  I  PS  CONGRESS,  (1968),  P.593-596 

SIMPLE 


DOWNS,  H  P  NIELSFN,  N  R 

WAT AN ABF,  F  T 

SIMULATION  OF  THE  ILLIAC  IV  -  P6500  R  EAL-T IMF  COMPUTING 
SYSTEM 

PROC.  FOURTH  CONF.  ON  APPLICATIONS  OF  SIMULATION  ACM/AIIE/ 
IEFE/S HA RE/SCI/TIMS  NEW  YORK, NFW  YORK  (DEC. 1970),  P.207-212 
FORTRAN  BURP HUGHS/ 6 500  APPLICATIONS 


EVANS,  G  W  WALLACE,  G  F 

SUTHERLAND,  G  L 

SIMULATION  USING  DIGITAL  COMPUTERS 
PRENTICF-HALL ,  INC.  ( 1 °6  7 ) 


FAMOLARI,  E 

FOPSIM  IV  -  FORTRAN  IV  SIMULATION  LANGUAGE  USER'S  GUIDE 
SR-99  MITRE  CORP.  (JAN. 1964) 

FORSIM 
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F0004 


FO007 


F0010 


F0020 


GOOIO 


G00?0 


G0025 


G0030 


G0040 


FINE,  G  H  MCISAAC,  P  V 

SIMULATION  OF  A  TI MR  SHARING  SYSTEM 
MANAG.  SCI.  12,6  (FEB. 1966),  P.180-194 
APPLICATI ONS 


FOX,  II  KESSLER,  J  L 

EXPCRIMPNTS  IN  SOFTWARE  MODELING 
PROC.  AFIPS  FJCC  (1967),  VOL. 31,  P.  429-438 
APPLICATIONS 


FREEMAN,  C  E 

DISCRETE  SYSTEMS  SIMULATION 
SIMULATION  7,3  (SEPT. 1966),  P.142-148 
GPSS 


FRFEMAN,  C  E 

PROGRAMMING  LANGUAGES  EASE  DIGITAL  SIMULATION 
CONTR.  CN  G.  (NOV. 1964),  P.  103-106A 
CSL  GPSS  SIMSCRIPT 


GAINEN,  L 

COMPLcX  BUSINESS  PROBLEMS?  TRY  SIMSCRIPT,  A  POWERFUL 
SIMULATION  LANGUAGE 

COMPUTER  DECISIONS  (APRIL  1970),  P.52-56 
SIMSCRIPT 


GEISLER,  M  A  MARKOWITZ,  H  M 

A  BRIFF  REVIEW  OF  SIMSCRIPT  AS  A  SIMULATING  TECHNIQUE 
RAND  CORP.  RM-3778-PR  (AUG. 1963) 

SIMSCRIPT 


GLINKA,  L  R  BRUSH, 

UN GAR,  A  J 

DESIGN,  THRU  SIMULATION, 
SYSTEM 

PROC.  AFIPS  FJCC  (1967), 
APPLICATIONS 


R  M 

OF  A  MULTIPLE-ACCESS  INFORMATION 
VOL. 31,  P.437-447 


CORDON,  G 

SIMULATION  LANGUAGES  FOR  DISCRETE  SYSTEMS 

PROC.  IBM  SCIENTIFIC  COMPUTING  SYMPOSIUM  SIMULATION  MODELS 
AND  GAMING  (1966),  P.101-118 


GORDON,  G 

SYSTEM  SIMULATION 

PRENTICE-HALL,  INC.  (1969) 


** 
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G0060 


MOOIO 


hoo?o 


H0030 


H0033 


H0036 


H0040 


H0045 


H0050 


GREENPERGFR,  V  JON^S,  M  H 
MORRIS,  J  H  NESS,  D  N 

ON-LINF  COMP UT ATI ON  AND  SIMULATION:  THE  OPS-3  SYSTEM 
THC  MIT  PRFSS  (  AUG.  I  9t>5 ) 

CPS3 


HAWTHORNE,  G  B 

DIGITAL  SIMULATION  AND  MODELING 
THF  MITRE  CHRP.  SR-I1 1  (MARCH  1964) 


HERMAN,  0  J 

SC P H T :  A  COMPUTER  ^VALUATION  TOOL 
DATAMATION  ( FFR  •  1967) ,  P.76-28 

SCERT 


HERMAN,  D  J  IHRER,  F  C 

THF  USE  OF  A  COMPUTER  TO  EVALUATE  COMPUTERS 

PPPC.  SJCC  (1964)  SPARTAN  BOOKS,  WA SH I NG TON , DC  P.383-395 

SC  c  R  T 


HILLS,  P  P 

SIMON:  A  SIMULATION  LANGUAGE  IN  ALGOL 
DIGITAL  SIMULATION  IN  OPERATIONAL  RESEARCH, 

ED.  S.H.HOLLI NGDALE,  (1967),  LECTURES  PRES.  AT  NATO 
SCIENTIFIC  AFFAIRS  CONF.  ,  HAMBURG,  GERMANY,  (SEPT.  1<365), 
P.  105-115 
SIMON 


HOARE,  CAR 
RECORD  HANDLING 

PROGRAMMING  L ANGUAGF S ,  NATO  ADVANCED  STUDY  INSTITUTE, 
LECTURES  DELIVERED  AT  NATO  SUMMER  SCHOOL,  VI LL AR0-OE-LANS , 
ACADEMIC  PRESS,  (1968),  P.324-336 


HOLLAND,  R  C  MFRIKALLIO,  R  A 

SIMULATION  OF  A  MULTIPROCESSING  SYSTEM  USING  GPSS 
I E  E c  TRANSACTIONS  ON  SYSTEMS  SCIENCF  AND  CYBERNETICS 
(NOV.  1968)  VOL.  SSC-4,  NO. 4,  P.395-400 
GPSS 


HOLLINGDALE,  s  h 

DIGITAL  SIMULATION  IN  OPERATIONAL  RESEARCH 

LECTURES  DCL I V.  AT  NATO  SCIENTIFIC  AFFAIRS  CONF.,  HAMBURG, 
GERMANY,  AMER.  FLSEVI^R  PUB.  CO.,  (1967) 


HUC  SMAN ,  L  R  GOLDBERG,  R  P 

EVALUATING  COMPUTER  SYSTEMS  THROUGH  SIMULATION 

COMPUTER  J.  10,2  (AUG. 1967),  P.150-156 

SC  CRT  CTSS  SIMSCRTPT  SIMTRAN  CSS  MOL  APPLICATIONS 
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H0053  HUGHES  AIPCRAFT  GROUND  SYSTEM  GROUP 

A  TOOL  FOR  THF  DEVELOPMENT  OF  REAL-TIME  COMPUTER  SYSTEMS 
(PRODUCT  LINE  SIMULATOR) 

HUGHFS  AIRCRAFT  CO,  NO. 05256-2,  (AUG. 1970) 

PL  S 


H0057  HUTCHINSON,  G  K 

SOME  PROB  LCMS  IN  THF  SIMULATION  OF  MULT  I PROC FSS OR  COMPUTER 
SYSTEMS 

SIMULATION  PROGRAMMING  LANGUAGES  (1968)  PROC.  OF  IFIP 
WORKING  CONFERENCE  ON  SIMULATION  LANGUAGES,  OSLO,  NORWAY 
(1967),  P.305-’24 

APPL ICATIPNS 


H0060  HUTCHINSON,  G  K  MAGUIRE,  J  N 

COMPUT CR  SYSTEMS  DESIGN  AND  ANALYSIS  THROUGH  SIMULATION 
PROC.  F Jf  C  (1965),  P.161-167 
SIMSCRIPT  UNIVAC/11C7  APPLICATIONS 


10003  IBM 

BIBLIOGRAPHY  ON  SIMULATION 
320-09  ?4- C  IBM  (1966) 


100)0  IBM  APPLICATION  PROGRAM 

GENERAL  PURPOSE  SIMULATION  SYSTEM/360  APPLICATION 
DESCRIPTION 

IBM  (1966, ’967),  H20-0186-2 
GPS  S 


IOOPO  IBM  APPLICATION  PROGRAM 

GENERAL  PURPOSE  SIMULATION  SYSTEM/360  INTRODUCTORY  USER'S 
MANUAL 

IBM  (1067),  H20-0304-1 
GPSS 


10030  IBM  APPLICATION  PROGRAM 

GENERAL  PURPOSE  SIMULATION  SYSTEM/360  USER'S  MANUAL 

IBM  (1067,1968),  H  20-0  326- 2 

GPSS 


1 003  8  IBM  APPLICATION  PROGRAM 

GENERAL  PURPOSE  SYSTEMS  SIMULATOR  III  INTRODUCTION 
GB20-0001-0  IBM  (FRB.1970) 

GPSS 


110 


10040  IBM  OAT A  PROCESSING  APPLICATION 

GENERAL  purpose  systems  simulator  ii 

I  PM  (1963),  820-6^46-1 
GPSS 


J0020  JONES,  M  M 

ON-LINE  SIMULATION 

PROC.  2?N  C  NAT,  CHNF.  ACM  PUB.  P-67,  (1967),  P.591-599 

UP  S3  0PS4 


K0005  KALINCHENKO,  L  A 

slang  -  COMPUTER  DESCRIPTION  and  simulation-op ientfo 
EXPERIMENTAL  PROGRAMMING  language 

SIMULATION  PROGRAMMING  LANGUAGES  ( 1 969 )  PROC.  OF  IFIP 
WORKING  CONFERENCE  TN  SIMULATION  LANGUAGES,  OSLO,  NORWAY 
(1967),  P.101-116 

SLANG 


K0010  KATZ,  J  H 

AN  EXPERIMENTAL  MODEL  OF  SYSTEM/360 

Communications  OF  THE  ACM  (NOV. 1967),  VOL. 10,  NO.H, 
P. 6Q4-702 

SIMSCRIPT  IBM/360  APPLICATIONS 


K 0 0 R 0  KATZ,  J  H 

SIMULATION  OF  A  MULTIPROCESSOR  COMPUTER  SYSTEM 
PPOC.  SJCC  (1.966),  VOL.  28,  P.127-139 
APPLICATIONS 


K0025  KFLLFY,  0  H  BUXTON,  J  N 

MONTEC00E  -  AN  INTERPRETIVE  PROGRAM  FOR  MONTE  CARLO 

COMPUTFR  J.  (JULY  1962),  VOL. 5,  P.88-93 

MONTECODE 


K0030  K I  V  I  AT ,  P  J 

DEVELOPMENT  OF  DISCRETE  DIGITAL  SIMULATION  LANGUAGES 
SIMULATION  8,2  (FEB.1967),  P.65-70 


K0040  K  I V  I  AT ,  P  J 

DEVELOPMENT  OF  NEW  DIGITAL  SIMULATION  LANGUAGES 
P-3348,  RAND  CORP.,  SANTA  MONICA,  CALIF.,  (APRIL  1966) 


K0050  KIVIAT,  P  J 

CIGITAL  COMPUTER  SIMULATION:  COMPUTER  PROGRAMMING  LANGUAGES 
RM-58R3-PR  RAND  CORP.,  SANTA  MONICA,  CALIF.,  (JAN. 1969) 

CSL  GPSS  SIMSCRIPT  SIMULA 
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K0060  KIVIAT,  P  J 

DIGITAL  COMPUTER  SIMULATION:  MODFLING  CONCEPTS 
RM-537B-PP  RANO  CORP.t  SANTA  MONICA,  CALIF,,  (AUG.1967) 


K0070  KIVIAT,  P  J 

INTRODUCTION  TO  THE  SIMSCRIPT  II  PROGRAMMING  LANGUAGE 
CIGfST  OF  THE  SECOND  CONFERENCE  ON  APPLICATIONS  OF 
SIMULATION  (DEC. 1968),  P.32-36 
SIMSCPIPT 


KC074  KIVIAT,  P  J  VILLANUEVA,  P  ** 

MARKOWITZ,  H  M 

THE  SIMSCPIPT  II  PROGRAMMING  LANGUAGE 
PRRNT ICE-HALL,  INC.  ( 1 968 ) 

SIMSCRIPT 


K0077  KIVIAT,  P  J  SHUKIAR,  H  J 

URMAN,  J  B  VILLANUEVA,  R 

THF  SIMSCRIPT  II  PROGRAMMING  LANGUAGE:  IBM  360 
I  VPLE  MF  NT  AT  I  ON 

RM-S777-PR  RAND  COPP.  (JULY  196«) 

SIMSCRIPT 


KOOPO  KLFIN^,  H 

A  SURVEY  OF  USFRS'  VIFWS  OF  DISCRETE  SIMULATION  LANGUAGES 
SIMULATION  (MAY  1970),  P.225-229 


K0090  KNUTH,  D  F  MCNFLEY,  J  L 

A  FORMAL  DEFINITION  OF  SOL 
IEEE  TRANS.  EC-13  (AUG. 1964),  P.409-414 
SOL 


K0100  KNUTH,  0  E  MCNFLEY,  J  L 

SOL  -  A  SYMBOLIC  LANGUAGE  FOR  GENERAL-PURPOSE  SYSTEM 
SIMULATION 

1FEE  TRANS.  EC-13  (AUG. 1964),  P.401-408 
SCL 


KOI  03  KOSY,  D  W 

EXPERIENCE  WITH  THE  EXTENDABLE  COMPUTER  SYSTEM  SIMULATOR 
FOURTH  CONF.  ON  APPLICATIONS  OF  SIMULATION,  ACM/A  I  I E/ I EEE/ 
SHARE/SCI /T IMS  NFW  YORK, NEW  YORK  (0EC.1970),  P.235-242 
EC  SS 

APPL ICAT IONS 
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KOI  0« 


K  0 1 1  0 


KOI  20 


KOI  30 


KOI  40 


L0003 


10010 


M00Q3 


MOOOS 


M0920 


KRASNOW,  h  s 

dynamic  representation  in  DISCRETE  interaction  simulation 
LANGUAGES 

digital  simulation  in  operational  research, 

ED.  S.H.HnLLINGDALE,  (1067),  LECTURES  PRES.  AT  NATO 
SCIENTIFIC  AEEAIRS  CONE.,  HAMBURG,  GERMANY,  (SEPT. 19651, 
P.77-92 

CSL  GPSS  GSP  SIMSCRIRT  SIMULA  SOL  MI  LI  TRAN 


KRASNOW,  H  S 

HIGHLIGHTS  OE  A  DYNAMIC  SYSTEM  DESCRIPTION  LANGUAGE 

IBM  ADV.  SYSTEMS  DEVELOPMENT  DIV.  TECHNICAL  REPORT  17-195 

NS  S 


KRASNOW,  H  S 

SUMMARY  REPORT:  I NTRRNAT I ONAL  FEDERATION  OE  INFORMATION 

PRHCFSSING  working  conference  on  simulation  languages 

SIMULATION  (FEB. 1968),  P.7°-90 


KRASNOW,  H  S  MER IK ALL  10,  P  A 

THR  PAST,  PRESENT,  AND  FUTURE  OF  SIMULATION  LANGUAGES 
MAN.  SCI.  11,  ( NOV .1964) ,  P.236-267 

CSL  DYNAMO  GPSS  SIMPAC  SIMSCRIPT 


KRIBS,  P 

SHARE  DIGITAL  SIMULATION  GLOSSARY 
SDC  S  P-1  562  (FRR.2D, 1964 ) 


LACKNEP,  M  R 

TOWARD  A  GENFRAL  SIMULATION  CAPACITY  (SIMPAC) 
WESTERN  JOINT  COMPUT.  CONF.  (1962),  P.1-14 
SI MPAC 


LEHMAN,  M  M  ROSENFELD,  J  L 

PERFORMANCE  OF  A  SIMULATED  MULTIPROGRAMMING  SYSTEM 
PROC.  FJCC  (1968),  VOL. 33,  PART  2,  P.1431-1442 
APPLICATIONS 


MACDOUGALL,  M  H 

COMPUTER  SYSTEM  SIMULATION:  AN  INTRODUCTION 
COMPUTING  SURVEYS  (SERT.1970),  VOL. 2,  NO. 3,  P.191-209 


MACOOUGALL,  M  H 

SIMULATION  OF  AN  FCS-BAS  ED  OPERATING  SYSTEM 
PROC.  AFIPS  SJCC  (1967),  VOL. 30,  P.735-741 
APPL  ICAT IONS 


MARTIN,  F  F 

COMPUTER  MODELING  AND  SIMULATION 
JOHN  WILEY  AND  SONS,  INC.  (1968) 
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M0026 


MOO?  9 


MOO^O 


M0040 


M0050 


M0C60 


M0070 


NOOl  0 


MC AUL AY,  S  E 

JCmSTREAM  SIMULATION  USING  A  CHANNEL  MULT  I  PROGRAMING  FEATURE 
PRUC.  FOURTH  CONF.  ON  APPLICATIONS  OF  SIMULATION  ACM/AIIE/ 
IEEF/SHARE/SCI/TIMS  NEW  YORK, NEW  YORK  (DEC. 1970),  P.190-194 
CSS  IBM/360  APPLICATIONS 


MCf  RED  I E ,  J  W  SCHLESINGER,  S  J 

A  MODULAR  SIMULATION  OF  TSS/360 
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